Challenges of indoor mapping formats
Sánchez Ortega, Iván (MazeMap AS)
New data formats for mapping the indoor spaces of buildings have been appearing lately - the shift from Autocad files to BIM systems and the adoption of OGC IndoorGML should mean a better standardization of the data. The reality from the trenches is somehow more grim - indoor mapping data is still in silos, hasn't seen any big breakthroughs in creating and editing, and most of the challenges remain. Sometimes a format or specification covers a very specific and non-general use case, and sometimes the generality of a format incurs in a great overhead for every simple use case. Sometimes new concepts are really old concepts from a different industry but with a new name. This talk will review what's good, what's bad and what's ugly with indoor mapping.
 Cool. So this is challenges in Indormaping formats basically working in Norwegian company called MazeMap. We do Indormaps. So this is just some ramblings about what I think of the formats. I'm going to talk about games. I'm going to talk about this video game, Wolfstein 3D. If you are like 30 years old, you have played this game. It was quite controversial, especially in Germany because it was the first game ever to feature Nazi soldiers in a video game. It was banned and I don't know if that's still true, but I'm not here to talk about the theme of the game. I'm here to talk about the technology of the game. This game was not the first to feature great tracing, which is something that goes back to one year before in Catacom 3D. This was actually the first person shooter ever. One of the first implementations, not the first, but one of the first implementations of raycasting. So if you look at the data model for this game, this is level one in Wolfstein 3D. It's just a 64-by-64 cell raster. You know what a raster is and you know you can do map maps with rasters. This was actually a raster map. The raycasting technique, if you know it, consists in casting a ray from the eye. You just cast a ray in a straight direction and you measure how long until that ray hits a wall. The point where it hits a wall defines the texture that you're going to use for that vertical line in your game screen. I think that's easy to do. A bit later, and a couple years later in 94, there was this game which is Rise of the Triad. This game implemented the first elevation techniques. If you look at the screenshot closely, you will see some of these platforms are more elevated than others. So the data format is just the same raster, but with more attributes with an elevation attribute. Next is Doom and Doom II. This come a few years later, in 1993 and 1995 respectively. These were a big jump in the technology of first-person shooter games. They had ground and ceiling elevation. You can have stairs, you can have high ceilings, low ceilings, you can have lifts. There are floating enemies and the shapes, as you can see in the video, they're completely regular. Before, it was all square and placement grid. So the data format, whoa, nope. Yes, so the data format is actually vectorial. It's vectors. This is a screenshot of a very old editor. This is the kind of features that were used back in the day, not really user-friendly. This is one of the most recent ones, which helps a lot to see more entities. In Doom, the data format is vertices first, then you join vertices with line-diff, then those line-diff are split into side-diff, and you get sectors. A sector is a set of closed rings of line-diff, of side-diff. That's it. You don't make the rings with lines, you make the rings with sides, and then an algorithm splits those sectors in sub-sectors. The big algorithmic gain from Doom was something called binary space partition. When you got the Doom map, the algorithm started drawing lines which were splitting the space. If you got something like a sector with another sector, polyon with a hole, the algorithm will start splitting lines and will make sub-sectors and portals between those sub-sectors. These will be insanely fast. This is the terminology. Transversing this BSP tree for visibility is so much faster than raycasting. Here you will see a backtracking algorithm in action. The algorithm will do a depth search, will render walls, then will go back to the start node, and will keep rendering the depth first until all the scene has been rendered. With raycasting, you should be doing a much less efficient search. This set. Then comes Duke Nukem. A couple years later. Duke Nukem was also quite a leap in technology. It was the first game where you could look up and down. I'm not counting Destin 3D because I got headaches with that. It got mirrors. It got open-reppened sectors. You could modify the game map on the fly. If you have looked at this video closely, you have noticed the elevator. The elevator is a sector and it's moving across. The BSP tree of what is going to be rendered is being modified as the sectors move around. Whenever you destroy it in a scenery, you actually modified the tree. If the wall was intact, you wouldn't care to render. You wouldn't care to search what is going to be rendered behind the wall because the wall is there and the BSP tree does not enter there. A couple years later, Sado Warrior, it was not a very big improvement, but it added something which was interesting to note, which is voxels. The objects in the game were not sprites facing the camera or facing the eye of the user. We're actually objects that you could run around and would take different shapes. If you notice, the medkit is slanted, respected to the user, so that's an example of voxels being used. It improved a few things over the Duke Nukemgyn, but not a lot. It was not such a big hit in technological terms. Then came the big hit, which was Quake. From 1996, I guess you know this or Quake 2. Quake was the first FPS to have true 3D, not just 2.5 3D. All the games up to that point were 2.5. It's good noting that this is completely 3D and not based in sectors, and you can just see the top of the bridge and the bottom of the bridge at the same time from the same camera. This was not possible in previous games. This was quite a leap in technology. It also uses BSP, but not with lines, but with planes. This is 3D space, not 2D space. The tools of the game pre-calculate some data from the game so you can play it. Instead of drawing sectors, you draw convex polyhedral, which are solid. Then the game makes the negative space that you can walk in. This is how it looks. You draw the blue and red shapes, and then the algorithm detects which is inside and outside, and makes a file with only the inside data and completely skips the outside. This is being done with BSP technology since Quake. Then came Half-Life from 1998. This was a revolution, not in technology, but in storytelling, really. This was the first game to not have a manual explaining what the game is about. The game itself gave you the whole environment of why you are in the game. These featured modifiable textures in the form of decals and a lot of part-funding AI. The game was praised for the part-finding algorithms. In previous games, the enemies just flow-streaded you. In Half-Life, you actually placed these AI nodes around, and then the algorithm run the BSP algorithm to check for inside-outside, and also made this connectivity graph. You can see how a human-sized object or entity can traverse some of the nodes. It doesn't look very good in the image, but here there is a red line, which is between these two nodes. That means that a human cannot travel between those lines. This was quite good. It's still not perfect AI, because you have to hint it, but it was a very good improvement. In all of video games, we are here to talk something serious, right? Not funny stuff. Okay, DWG in 1982, this was a data format created by Autodesk for AutoCAD. And it's proprietary, and it's 2D, and it has 3D. This is AutoCAD only. So a thing that AutoCAD made and Autodesk made back in the days is create DXF in the same year. And DXF is the data interchange format. That's why the DXF letters. There is a specification available. It's 2D, 3D, but it doesn't support all the features that DWG supports. So it's kind of, okay, we got this for free. You can see the specification. You can make your own libraries to read the format, but the good stuff we're going to keep for ourselves. So right now, the libraries who are the utilities, which can read DWG and convert to something else, might be buggy. They don't support a full range of things that you can do in AutoCAD. They tend to crash. They tend to not extract all the information. So it's not really good. And DXF is not useful because it's only for export. And again, AutoCAD does not export everything as per the specs. Also, it has quite a few problems. When you look at them, when you look at the typical AutoCAD data plan, you see a lot of lines that don't make any sense. In this example, I can see the floor is like in lines, which makes me think it's a wooden floor. And the walls are in squares, which makes me think they are like porcelain tiles. There are people for scale. And there are a lot of things that don't make any sense at all. These formats tend to have a similar set of problems whenever you encounter them. They have a lot of lines that don't make any sense. They just for making the map beautiful and readable. It's like in OpenStream app parlance, this is mapping for the renderer. Or in this case, mapping, creating technical entities. So the person reading the map understands the map. The layers are not semantic. In AutoCAD, you can make layers like doors, walls, pressure points, load-burying walls, et cetera. But a lot of times you end up with something like that. And when it's not something like that, it's 30 layers like that. And you have to guess which one of that has the doors. And maybe the layer which has the doors has also chairs for some reason. I don't know why, but this happens with DXF. Also, you have seen this rendering of buildings. Whenever you see a new building being built, the people marketing them have this beautiful fake photographs of them. They're beautiful, okay? I get it. They're not really that useful. They cannot convey any information about load-burying. They cannot convey a lot of information about volume. They don't have any data that really makes them useful for anything else than making a pretty photograph on a marketing brochure. Then a couple years later, you have this explosion of building information modeling software, which is pretty cool, right? It applies some semantic meaning to things of the building. You actually have some very explicit features for power or some very explicit features for water or heating or things which can have any sensors on them, like light sensors, volumetric sensors, opened or closed doors, et cetera. The main problem with beam formats is that each vendor of beam has a different concept of reality. So each vendor of beam will model a building in a very different way. Some beams don't care about doors. Some other beams only care about doors. Some beams don't care about linear features because they only handle points. Some other beams handle everything in 3D and it's a mess of compatibility. You basically cannot make anything compatible. And a couple of years ago, we have these internal things craziness, complete craziness. Do I have time? Yes, I have five minutes, I'm perfectly good. Actually, I really recommend, if you can, if you're one of these people who from, who are on Twitter and have a sense of humor and you're interested in the internal things, I really, really, really recommend you follow the internet of shit. This will give you a very good insight on why the internet of shit is nothing but air, what we say in Spain. They are just selling smoke. The internet of things does not work as of today. We don't need a Bluetooth connected toothbrush, no matter what they say to me. And the problem with internal things is it's not compatible with anybody else. All the vendors, if you read all these articles, you will learn that the internal things, they are there to make you depend on one vendor. They are not going to make the device compatible with anything else. If the company who sold you the thermostat decides to block the thermostat, you're fucked. You cannot use the thermostat with anything else. So if you're trying to make any use of the things of the internet of things with building information modeling, I say to you, good luck. Okay, a few couple years later on this, CTGML, this is an evolution of GML. It defines things like level of detail, materials for the building walls and roads, defines ceiling types and that stuff. Later, we got Indoor GML a couple years ago. This is an evolution of CTGML, which defines more materials, more furniture, room types. It also defines indoor and outdoor space. It also defines room connectivity. It also defines routine paths with path finding hints. It defines a lot, a lot, a lot of things. Now I'm going to make a puff quiz. Who can guess? I work for a company which actually does Indoor Maps. Our clients are people with buildings, who own buildings and who want maps of buildings. Who can guess the number of people that ask my company about Indoor GML? I see a zero there and a zero there and a zero there and you are right. There are zero people in the world asking for Indoor GML. Which tends me to think that the current state of Indoor mapping formats is like this. Games are absolutely wonderful at handling indoor spaces. They're absolutely wonderful. It's what they have been doing for 20 years. But obviously they are very good at making computations with them. They're very good at making path finding with them and visibility checks with them and all this kind of things. If you're trying to guess the inside and outside of a building, game algorithms is the way to go. If you want to actually build a building, you have to use DWG. All the architects in the world are using AutoCAD whether we like it or not. As well as the rest of the world in GIS who are not in the FOSFIG, they use Esri. Architects use Autodesk. That's it. With obviously notable exceptions, but a lot of people just use that. And you cannot, it's very, very hard to go to an architect and say give me something that is not an AutoCAD file. If you want to sell stuff which is connected to the internet, go for BIM, absolutely. Just make sure that your stuff is not compatible with anybody else. And if you want to try and be good at everything and fail at everything, you use IndoorGML. So that's all. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you! Are you an agreement by Joe Krubber? Yes? Who is an agreement by an agreement, by Joe Krubber.لب necks of course. I wanted an agreement by geworden Excuse me. In the end, your conclusion was rather, was a dark outlook, it seemed like. But wouldn't you have any, any brighter outlook? Is, would you think in a couple of, because 2014 is like yesterday. So might not be that much time to, to become this standard. Could it be anything in the future that works better like that? I'm not really sure. Really. I'm not optimistic about this. We handle building data every day of my company and it's a mess. Right now it's a mess. I don't see any solution, any easy solution right out of the door. Right. I have also sold indoor open stream map. I don't think it's there yet. It's very tightly coupled to indoor GML. The future is going to be AutoCAD more and more. Because if you have built a building in the Western world, that is to, that is an important remark. If you have built a building in the Western world with plants and architects, the building is going to have AutoCAD files for it. So how can we fix AutoCAD files not serving the purposes that we want? That's a question I don't have the answer for. We can try to process those files and extract more and more information and make it look like a video game, actually. That's actually something that we have joked about in my office. But it's not a joke. Video games are absolutely awesome. I wish, I really, really wish that architects would care for data consistency, but they don't. Architects care about the final map printed in that A1 sheet of paper looks good. They don't care for anything else. Right now, architects don't realize that the data they do, which is a file, not a piece of paper, that data can't have for their users. They just do the job, send them up, get paid, it's over. They don't think that if you open up the data and if you care for the quality of the data, other people can have brighter ideas of what to do with the data. So the architect world doesn't have that mindset yet. And if the people trying to hit that mindset are selling beam formats, so you should care for the semantics of your building, but in my specific format for my specific set of devices. This is going to take time. Okay. I can comment this architect world worked with them lately. At least like 10% of architects are working in beam nowadays. They are not using AutoCats. They are using Gravit, for example, and for data exchange they are using IFC models. I think in Spain and in some countries there are standards for IFCs, which is kind of DXF for beam models. So do you have experiences working with those? Actually no. In my company, we haven't yet had a client which has this kind of format, unfortunately. I would love to have a look, but I don't have any firsthand experience in it. That could be a future, not only for Internet of Things, but just for architecture, what makes sense because the DXF AutoCat formats are just drawings. But architects are understanding. They need the GIS also, and GIS for buildings is a beam. I'm not convinced yet that BIM is a way to go. I'm not sure. I haven't seen that. The people pushing for BIM are selling domotics and are selling some kind of automatism. They are not caring for the kind of unexpected applications of technology that we open source people care about. So I don't have to wait and see. I don't have to wait and see. I'm sorry if I'm pessimistic about this, but that's my point of view. Well, I think we can give you another round of applause.
 Cool. So this is challenges in  Indormaping formats basically working in  Norwegian company called MazeMap.  We do Indormaps.  So this is just some ramblings about what I think of the formats.  I'm going to talk about games.  I'm going to talk about this video game, Wolfstein 3D.  If you are like 30 years old,  you have played this game.  It was quite controversial,  especially in Germany because it was the first game ever to  feature Nazi soldiers in a video game.  It was banned and I don't know if that's still true,  but I'm not here to talk about the theme of the game.  I'm here to talk about the technology of the game.  This game was not the first to feature  great tracing, which is something that goes back to  one year before in Catacom 3D.  This was actually the first person shooter ever.  One of the first implementations,  not the first, but one of the first implementations of raycasting.  So if you look at the data model for this game,  this is level one in Wolfstein 3D.  It's just a 64-by-64 cell raster.  You know what a raster is and you know you can do  map maps with rasters.  This was actually a raster map.  The raycasting technique, if you know it,  consists in casting a ray from the eye.  You just cast a ray in a straight direction and you measure  how long until that ray hits a wall.  The point where it hits a wall defines  the texture that you're going to use for that vertical line in your game screen.  I think that's easy to do.  A bit later, and a couple years later in 94,  there was this game which is Rise of the Triad.  This game implemented the first elevation techniques.  If you look at the screenshot closely,  you will see some of these platforms are more elevated than others.  So the data format is just the same raster,  but with more attributes with an elevation attribute.  Next is Doom and Doom II.  This come a few years later,  in 1993 and 1995 respectively.  These were a big jump in the technology of first-person shooter games.  They had ground and ceiling elevation.  You can have stairs, you can have high ceilings, low ceilings,  you can have lifts.  There are floating enemies and the shapes,  as you can see in the video,  they're completely regular.  Before, it was all square and placement grid.  So the data format, whoa, nope.  Yes, so the data format is actually vectorial.  It's vectors.  This is a screenshot of a very old editor.  This is the kind of features that were used back in the day,  not really user-friendly.  This is one of the most recent ones,  which helps a lot to see more entities.  In Doom, the data format is vertices first,  then you join vertices with line-diff,  then those line-diff are split into side-diff,  and you get sectors.  A sector is a set of closed rings of line-diff, of side-diff.  That's it.  You don't make the rings with lines,  you make the rings with sides,  and then an algorithm splits those sectors in sub-sectors.  The big algorithmic gain from Doom  was something called binary space partition.  When you got the Doom map,  the algorithm started drawing lines which were splitting the space.  If you got something like a sector with another sector,  polyon with a hole,  the algorithm will start splitting lines  and will make sub-sectors and portals between those sub-sectors.  These will be insanely fast.  This is the terminology.  Transversing this BSP tree for visibility is so much faster  than raycasting.  Here you will see a backtracking algorithm in action.  The algorithm will do a depth search,  will render walls,  then will go back to the start node,  and will keep rendering the depth first  until all the scene has been rendered.  With raycasting, you should be doing a much less efficient search.  This set.  Then comes Duke Nukem.  A couple years later.  Duke Nukem was also quite a leap in technology.  It was the first game where you could look up and down.  I'm not counting Destin 3D because I got headaches with that.  It got mirrors.  It got open-reppened sectors.  You could modify the game map on the fly.  If you have looked at this video closely,  you have noticed the elevator.  The elevator is a sector and it's moving across.  The BSP tree of what is going to be rendered  is being modified as the sectors move around.  Whenever you destroy it in a scenery,  you actually modified the tree.  If the wall was intact, you wouldn't care to render.  You wouldn't care to search what is going to be rendered  behind the wall because the wall is there  and the BSP tree does not enter there.  A couple years later, Sado Warrior,  it was not a very big improvement,  but it added something which was interesting to note,  which is voxels.  The objects in the game were not sprites  facing the camera or facing the eye of the user.  We're actually objects that you could run around  and would take different shapes.  If you notice, the medkit is slanted,  respected to the user,  so that's an example of voxels being used.  It improved a few things over the Duke Nukemgyn,  but not a lot.  It was not such a big hit in technological terms.  Then came the big hit, which was Quake.  From 1996, I guess you know this or Quake 2.  Quake was the first FPS to have true 3D,  not just 2.5 3D.  All the games up to that point were 2.5.  It's good noting that this is completely 3D  and not based in sectors,  and you can just see the top of the bridge  and the bottom of the bridge at the same time  from the same camera.  This was not possible in previous games.  This was quite a leap in technology.  It also uses BSP, but not with lines,  but with planes.  This is 3D space, not 2D space.  The tools of the game pre-calculate some data  from the game so you can play it.  Instead of drawing sectors,  you draw convex polyhedral, which are solid.  Then the game makes the negative space  that you can walk in.  This is how it looks.  You draw the blue and red shapes,  and then the algorithm detects which is inside and outside,  and makes a file with only the inside data  and completely skips the outside.  This is being done with BSP technology since Quake.  Then came Half-Life from 1998.  This was a revolution, not in technology,  but in storytelling, really.  This was the first game to not have a manual  explaining what the game is about.  The game itself gave you the whole environment  of why you are in the game.  These featured modifiable textures  in the form of decals and a lot of part-funding AI.  The game was praised for the part-finding algorithms.  In previous games, the enemies just flow-streaded you.  In Half-Life, you actually placed these AI nodes around,  and then the algorithm run the BSP algorithm  to check for inside-outside,  and also made this connectivity graph.  You can see how a human-sized object or entity  can traverse some of the nodes.  It doesn't look very good in the image,  but here there is a red line,  which is between these two nodes.  That means that a human cannot travel between those lines.  This was quite good.  It's still not perfect AI, because you have to hint it,  but it was a very good improvement.  In all of video games,  we are here to talk something serious, right?  Not funny stuff.  Okay, DWG in 1982,  this was a data format created by Autodesk for AutoCAD.  And it's proprietary, and it's 2D, and it has 3D.  This is AutoCAD only.  So a thing that AutoCAD made  and Autodesk made back in the days is create DXF  in the same year.  And DXF is the data interchange format.  That's why the DXF letters.  There is a specification available.  It's 2D, 3D, but it doesn't support all the features  that DWG supports.  So it's kind of, okay, we got this for free.  You can see the specification.  You can make your own libraries to read the format,  but the good stuff we're going to keep for ourselves.  So right now, the libraries who are the utilities,  which can read DWG and convert to something else,  might be buggy.  They don't support a full range of things  that you can do in AutoCAD.  They tend to crash.  They tend to not extract all the information.  So it's not really good.  And DXF is not useful because it's only for export.  And again, AutoCAD does not export everything  as per the specs.  Also, it has quite a few problems.  When you look at them,  when you look at the typical AutoCAD data plan,  you see a lot of lines that don't make any sense.  In this example, I can see the floor is like in lines,  which makes me think it's a wooden floor.  And the walls are in squares,  which makes me think they are like porcelain tiles.  There are people for scale.  And there are a lot of things  that don't make any sense at all.  These formats tend to have a similar set of problems  whenever you encounter them.  They have a lot of lines that don't make any sense.  They just for making the map beautiful and readable.  It's like in OpenStream app parlance,  this is mapping for the renderer.  Or in this case, mapping, creating technical entities.  So the person reading the map understands the map.  The layers are not semantic.  In AutoCAD, you can make layers like doors, walls,  pressure points, load-burying walls, et cetera.  But a lot of times you end up with something like that.  And when it's not something like that,  it's 30 layers like that.  And you have to guess which one of that has the doors.  And maybe the layer which has the doors  has also chairs for some reason.  I don't know why, but this happens with DXF.  Also, you have seen this rendering of buildings.  Whenever you see a new building being built,  the people marketing them  have this beautiful fake photographs of them.  They're beautiful, okay?  I get it.  They're not really that useful.  They cannot convey any information about load-burying.  They cannot convey a lot of information about volume.  They don't have any data that really makes them useful  for anything else than making a pretty photograph  on a marketing brochure.  Then a couple years later,  you have this explosion  of building information modeling software,  which is pretty cool, right?  It applies some semantic meaning to things of the building.  You actually have some very explicit features for power  or some very explicit features for water or heating  or things which can have any sensors on them,  like light sensors, volumetric sensors,  opened or closed doors, et cetera.  The main problem with beam formats  is that each vendor of beam has a different concept  of reality.  So each vendor of beam will model a building  in a very different way.  Some beams don't care about doors.  Some other beams only care about doors.  Some beams don't care about linear features  because they only handle points.  Some other beams handle everything in 3D  and it's a mess of compatibility.  You basically cannot make anything compatible.  And a couple of years ago,  we have these internal things craziness, complete craziness.  Do I have time?  Yes, I have five minutes, I'm perfectly good.  Actually, I really recommend,  if you can, if you're one of these people who  from, who are on Twitter and have a sense of humor  and you're interested in the internal things,  I really, really, really recommend  you follow the internet of shit.  This will give you a very good insight  on why the internet of shit is nothing but air,  what we say in Spain.  They are just selling smoke.  The internet of things does not work as of today.  We don't need a Bluetooth connected toothbrush,  no matter what they say to me.  And the problem with internal things  is it's not compatible with anybody else.  All the vendors, if you read all these articles,  you will learn that the internal things,  they are there to make you depend on one vendor.  They are not going to make the device  compatible with anything else.  If the company who sold you the thermostat  decides to block the thermostat, you're fucked.  You cannot use the thermostat with anything else.  So if you're trying to make any use of the things  of the internet of things with building  information modeling, I say to you, good luck.  Okay, a few couple years later on this,  CTGML, this is an evolution of GML.  It defines things like level of detail,  materials for the building walls and roads,  defines ceiling types and that stuff.  Later, we got Indoor GML a couple years ago.  This is an evolution of CTGML,  which defines more materials, more furniture, room types.  It also defines indoor and outdoor space.  It also defines room connectivity.  It also defines routine paths with path finding hints.  It defines a lot, a lot, a lot of things.  Now I'm going to make a puff quiz.  Who can guess?  I work for a company which actually does Indoor Maps.  Our clients are people with buildings,  who own buildings and who want maps of buildings.  Who can guess the number of people  that ask my company about Indoor GML?  I see a zero there and a zero there and a zero there  and you are right.  There are zero people in the world asking for Indoor GML.  Which tends me to think that the current state  of Indoor mapping formats is like this.  Games are absolutely wonderful at handling indoor spaces.  They're absolutely wonderful.  It's what they have been doing for 20 years.  But obviously they are very good  at making computations with them.  They're very good at making path finding with them  and visibility checks with them  and all this kind of things.  If you're trying to guess the inside and outside  of a building, game algorithms is the way to go.  If you want to actually build a building,  you have to use DWG.  All the architects in the world are using AutoCAD  whether we like it or not.  As well as the rest of the world in GIS  who are not in the FOSFIG, they use Esri.  Architects use Autodesk.  That's it.  With obviously notable exceptions,  but a lot of people just use that.  And you cannot, it's very, very hard to go to an architect  and say give me something that is not an AutoCAD file.  If you want to sell stuff which is connected to the internet,  go for BIM, absolutely.  Just make sure that your stuff is not compatible  with anybody else.  And if you want to try and be good at everything  and fail at everything, you use IndoorGML.  So that's all.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you!  Are you an agreement by Joe Krubber?  Yes?  Who is an agreement by  an agreement, by Joe Krubber. لب necks of course.  I wanted an agreement by geworden  Excuse me.  In the end, your conclusion was rather, was a dark outlook, it seemed like.  But wouldn't you have any, any brighter outlook?  Is, would you think in a couple of, because 2014 is like yesterday.  So might not be that much time to, to become this standard.  Could it be anything in the future that works better like that?  I'm not really sure.  Really.  I'm not optimistic about this.  We handle building data every day of my company and it's a mess.  Right now it's a mess.  I don't see any solution, any easy solution right out of the door.  Right.  I have also sold indoor open stream map.  I don't think it's there yet.  It's very tightly coupled to indoor GML.  The future is going to be AutoCAD more and more.  Because if you have built a building in the Western world, that is to, that is an important  remark.  If you have built a building in the Western world with plants and architects, the building  is going to have AutoCAD files for it.  So how can we fix AutoCAD files not serving the purposes that we want?  That's a question I don't have the answer for.  We can try to process those files and extract more and more information and make it look  like a video game, actually.  That's actually something that we have joked about in my office.  But it's not a joke.  Video games are absolutely awesome.  I wish, I really, really wish that architects would care for data consistency, but they  don't.  Architects care about the final map printed in that A1 sheet of paper looks good.  They don't care for anything else.  Right now, architects don't realize that the data they do, which is a file, not a piece  of paper, that data can't have for their users.  They just do the job, send them up, get paid, it's over.  They don't think that if you open up the data and if you care for the quality of the data,  other people can have brighter ideas of what to do with the data.  So the architect world doesn't have that mindset yet.  And if the people trying to hit that mindset are selling beam formats, so you should care  for the semantics of your building, but in my specific format for my specific set of  devices.  This is going to take time.  Okay.  I can comment this architect world worked with them lately.  At least like 10% of architects are working in beam nowadays.  They are not using AutoCats.  They are using Gravit, for example, and for data exchange they are using IFC models.  I think in Spain and in some countries there are standards for IFCs, which is kind of DXF  for beam models.  So do you have experiences working with those?  Actually no.  In my company, we haven't yet had a client which has this kind of format, unfortunately.  I would love to have a look, but I don't have any firsthand experience in it.  That could be a future, not only for Internet of Things, but just for architecture, what  makes sense because the DXF AutoCat formats are just drawings.  But architects are understanding.  They need the GIS also, and GIS for buildings is a beam.  I'm not convinced yet that BIM is a way to go.  I'm not sure.  I haven't seen that.  The people pushing for BIM are selling domotics and are selling some kind of automatism.  They are not caring for the kind of unexpected applications of technology that we open source  people care about.  So I don't have to wait and see.  I don't have to wait and see.  I'm sorry if I'm pessimistic about this, but that's my point of view.  Well, I think we can give you another round of applause.
foss4g-2016-1189-challenges_of_indoor_mapping_formats-hd_0_995.png foss4g-2016-1189-challenges_of_indoor_mapping_formats-hd_996_1163.png foss4g-2016-1189-challenges_of_indoor_mapping_formats-hd_1164_1379.png foss4g-2016-1189-challenges_of_indoor_mapping_formats-hd_1380_2459.png foss4g-2016-1189-challenges_of_indoor_mapping_formats-hd_2460_2663.png foss4g-2016-1189-challenges_of_indoor_mapping_formats-hd_2664_2795.png foss4g-2016-1189-challenges_of_indoor_mapping_formats-hd_2796_2891.png foss4g-2016-1189-challenges_of_indoor_mapping_formats-hd_2892_3455.png foss4g-2016-1189-challenges_of_indoor_mapping_formats-hd_3456_3563.png foss4g-2016-1189-challenges_of_indoor_mapping_formats-hd_3564_3695.png foss4g-2016-1189-challenges_of_indoor_mapping_formats-hd_3696_3779.png foss4g-2016-1189-challenges_of_indoor_mapping_formats-hd_3780_3827.png foss4g-2016-1189-challenges_of_indoor_mapping_formats-hd_3828_3971.png foss4g-2016-1189-challenges_of_indoor_mapping_formats-hd_3972_4067.png foss4g-2016-1189-challenges_of_indoor_mapping_formats-hd_4068_4127.png foss4g-2016-1189-challenges_of_indoor_mapping_formats-hd_4128_4559.png foss4g-2016-1189-challenges_of_indoor_mapping_formats-hd_4560_4763.png foss4g-2016-1189-challenges_of_indoor_mapping_formats-hd_4764_7499.png foss4g-2016-1189-challenges_of_indoor_mapping_formats-hd_7500_7811.png foss4g-2016-1189-challenges_of_indoor_mapping_formats-hd_7812_10955.png foss4g-2016-1189-challenges_of_indoor_mapping_formats-hd_10956_20687.png foss4g-2016-1189-challenges_of_indoor_mapping_formats-hd_20688_20783.png foss4g-2016-1189-challenges_of_indoor_mapping_formats-hd_20784_22847.png foss4g-2016-1189-challenges_of_indoor_mapping_formats-hd_22848_23315.png foss4g-2016-1189-challenges_of_indoor_mapping_formats-hd_23316_23627.png foss4g-2016-1189-challenges_of_indoor_mapping_formats-hd_23628_23879.png foss4g-2016-1189-challenges_of_indoor_mapping_formats-hd_23880_24755.png foss4g-2016-1189-challenges_of_indoor_mapping_formats-hd_24756_26963.png foss4g-2016-1189-challenges_of_indoor_mapping_formats-hd_26964_27011.png foss4g-2016-1189-challenges_of_indoor_mapping_formats-hd_27012_34475.png foss4g-2016-1189-challenges_of_indoor_mapping_formats-hd_34476_34571.png foss4g-2016-1189-challenges_of_indoor_mapping_formats-hd_34572_34691.png foss4g-2016-1189-challenges_of_indoor_mapping_formats-hd_34692_34847.png
Cool. So this is challenges in Indormaping formats basically working in Norwegian company called MazeMap. We do Indormaps. So this is just some ramblings about what I think of the formats. I'm going to talk about games. I'm going to talk about this video game, Wolfstein 3D. If you are like 30 years old, you have played this game. It was quite controversial, especially in Germany because it was the first game ever to feature Nazi soldiers in a video game. It was banned and I don't know if that's still true, but I'm not here to talk about the theme of the game. I'm here to talk about the technology of the game. This game was not the first to feature great tracing, which is something that goes back to one year before in Catacom 3D. This was actually the first person shooter ever. One of the first implementations, not the first, but one of the first implementations of raycasting. So if you look at the data model for this game, this is level one in Wolfstein 3D. It's just a 64-by-64 cell raster. You know what a raster is and you know you can do map maps with rasters. This was actually a raster map. The raycasting technique, if you know it, consists in casting a ray from the eye. You just cast a ray in a straight direction and you measure how long until that ray hits a wall. The point where it hits a wall defines the texture that you're going to use for that vertical line in your game screen. I think that's easy to do. A bit later, and a couple years later in 94, there was this game which is Rise of the Triad. This game implemented the first elevation techniques. If you look at the screenshot closely, you will see some of these platforms are more elevated than others. So the data format is just the same raster, but with more attributes with an elevation attribute. Next is Doom and Doom II. This come a few years later, in 1993 and 1995 respectively. These were a big jump in the technology of first-person shooter games. They had ground and ceiling elevation. You can have stairs, you can have high ceilings, low ceilings, you can have lifts. There are floating enemies and the shapes, as you can see in the video, they're completely regular. Before, it was all square and placement grid. So the data format, whoa, nope. Yes, so the data format is actually vectorial. It's vectors. This is a screenshot of a very old editor. This is the kind of features that were used back in the day, not really user-friendly. This is one of the most recent ones, which helps a lot to see more entities. In Doom, the data format is vertices first, then you join vertices with line-diff, then those line-diff are split into side-diff, and you get sectors. A sector is a set of closed rings of line-diff, of side-diff. That's it. You don't make the rings with lines, you make the rings with sides, and then an algorithm splits those sectors in sub-sectors. The big algorithmic gain from Doom was something called binary space partition. When you got the Doom map, the algorithm started drawing lines which were splitting the space. If you got something like a sector with another sector, polyon with a hole, the algorithm will start splitting lines and will make sub-sectors and portals between those sub-sectors. These will be insanely fast. This is the terminology. Transversing this BSP tree for visibility is so much faster than raycasting. Here you will see a backtracking algorithm in action. The algorithm will do a depth search, will render walls, then will go back to the start node, and will keep rendering the depth first until all the scene has been rendered. With raycasting, you should be doing a much less efficient search. This set. Then comes Duke Nukem. A couple years later. Duke Nukem was also quite a leap in technology. It was the first game where you could look up and down. I'm not counting Destin 3D because I got headaches with that. It got mirrors. It got open-reppened sectors. You could modify the game map on the fly. If you have looked at this video closely, you have noticed the elevator. The elevator is a sector and it's moving across. The BSP tree of what is going to be rendered is being modified as the sectors move around. Whenever you destroy it in a scenery, you actually modified the tree. If the wall was intact, you wouldn't care to render. You wouldn't care to search what is going to be rendered behind the wall because the wall is there and the BSP tree does not enter there. A couple years later, Sado Warrior, it was not a very big improvement, but it added something which was interesting to note, which is voxels. The objects in the game were not sprites facing the camera or facing the eye of the user. We're actually objects that you could run around and would take different shapes. If you notice, the medkit is slanted, respected to the user, so that's an example of voxels being used. It improved a few things over the Duke Nukemgyn, but not a lot. It was not such a big hit in technological terms. Then came the big hit, which was Quake. From 1996, I guess you know this or Quake 2. Quake was the first FPS to have true 3D, not just 2.5 3D. All the games up to that point were 2.5. It's good noting that this is completely 3D and not based in sectors, and you can just see the top of the bridge and the bottom of the bridge at the same time from the same camera. This was not possible in previous games. This was quite a leap in technology. It also uses BSP, but not with lines, but with planes. This is 3D space, not 2D space. The tools of the game pre-calculate some data from the game so you can play it. Instead of drawing sectors, you draw convex polyhedral, which are solid. Then the game makes the negative space that you can walk in. This is how it looks. You draw the blue and red shapes, and then the algorithm detects which is inside and outside, and makes a file with only the inside data and completely skips the outside. This is being done with BSP technology since Quake. Then came Half-Life from 1998. This was a revolution, not in technology, but in storytelling, really. This was the first game to not have a manual explaining what the game is about. The game itself gave you the whole environment of why you are in the game. These featured modifiable textures in the form of decals and a lot of part-funding AI. The game was praised for the part-finding algorithms. In previous games, the enemies just flow-streaded you. In Half-Life, you actually placed these AI nodes around, and then the algorithm run the BSP algorithm to check for inside-outside, and also made this connectivity graph. You can see how a human-sized object or entity can traverse some of the nodes. It doesn't look very good in the image, but here there is a red line, which is between these two nodes. That means that a human cannot travel between those lines. This was quite good. It's still not perfect AI, because you have to hint it, but it was a very good improvement. In all of video games, we are here to talk something serious, right? Not funny stuff. Okay, DWG in 1982, this was a data format created by Autodesk for AutoCAD. And it's proprietary, and it's 2D, and it has 3D. This is AutoCAD only. So a thing that AutoCAD made and Autodesk made back in the days is create DXF in the same year. And DXF is the data interchange format. That's why the DXF letters. There is a specification available. It's 2D, 3D, but it doesn't support all the features that DWG supports. So it's kind of, okay, we got this for free. You can see the specification. You can make your own libraries to read the format, but the good stuff we're going to keep for ourselves. So right now, the libraries who are the utilities, which can read DWG and convert to something else, might be buggy. They don't support a full range of things that you can do in AutoCAD. They tend to crash. They tend to not extract all the information. So it's not really good. And DXF is not useful because it's only for export. And again, AutoCAD does not export everything as per the specs. Also, it has quite a few problems. When you look at them, when you look at the typical AutoCAD data plan, you see a lot of lines that don't make any sense. In this example, I can see the floor is like in lines, which makes me think it's a wooden floor. And the walls are in squares, which makes me think they are like porcelain tiles. There are people for scale. And there are a lot of things that don't make any sense at all. These formats tend to have a similar set of problems whenever you encounter them. They have a lot of lines that don't make any sense. They just for making the map beautiful and readable. It's like in OpenStream app parlance, this is mapping for the renderer. Or in this case, mapping, creating technical entities. So the person reading the map understands the map. The layers are not semantic. In AutoCAD, you can make layers like doors, walls, pressure points, load-burying walls, et cetera. But a lot of times you end up with something like that. And when it's not something like that, it's 30 layers like that. And you have to guess which one of that has the doors. And maybe the layer which has the doors has also chairs for some reason. I don't know why, but this happens with DXF. Also, you have seen this rendering of buildings. Whenever you see a new building being built, the people marketing them have this beautiful fake photographs of them. They're beautiful, okay? I get it. They're not really that useful. They cannot convey any information about load-burying. They cannot convey a lot of information about volume. They don't have any data that really makes them useful for anything else than making a pretty photograph on a marketing brochure. Then a couple years later, you have this explosion of building information modeling software, which is pretty cool, right? It applies some semantic meaning to things of the building. You actually have some very explicit features for power or some very explicit features for water or heating or things which can have any sensors on them, like light sensors, volumetric sensors, opened or closed doors, et cetera. The main problem with beam formats is that each vendor of beam has a different concept of reality. So each vendor of beam will model a building in a very different way. Some beams don't care about doors. Some other beams only care about doors. Some beams don't care about linear features because they only handle points. Some other beams handle everything in 3D and it's a mess of compatibility. You basically cannot make anything compatible. And a couple of years ago, we have these internal things craziness, complete craziness. Do I have time? Yes, I have five minutes, I'm perfectly good. Actually, I really recommend, if you can, if you're one of these people who from, who are on Twitter and have a sense of humor and you're interested in the internal things, I really, really, really recommend you follow the internet of shit. This will give you a very good insight on why the internet of shit is nothing but air, what we say in Spain. They are just selling smoke. The internet of things does not work as of today. We don't need a Bluetooth connected toothbrush, no matter what they say to me. And the problem with internal things is it's not compatible with anybody else. All the vendors, if you read all these articles, you will learn that the internal things, they are there to make you depend on one vendor. They are not going to make the device compatible with anything else. If the company who sold you the thermostat decides to block the thermostat, you're fucked. You cannot use the thermostat with anything else. So if you're trying to make any use of the things of the internet of things with building information modeling, I say to you, good luck. Okay, a few couple years later on this, CTGML, this is an evolution of GML. It defines things like level of detail, materials for the building walls and roads, defines ceiling types and that stuff. Later, we got Indoor GML a couple years ago. This is an evolution of CTGML, which defines more materials, more furniture, room types. It also defines indoor and outdoor space. It also defines room connectivity. It also defines routine paths with path finding hints. It defines a lot, a lot, a lot of things. Now I'm going to make a puff quiz. Who can guess? I work for a company which actually does Indoor Maps. Our clients are people with buildings, who own buildings and who want maps of buildings. Who can guess the number of people that ask my company about Indoor GML? I see a zero there and a zero there and a zero there and you are right. There are zero people in the world asking for Indoor GML. Which tends me to think that the current state of Indoor mapping formats is like this. Games are absolutely wonderful at handling indoor spaces. They're absolutely wonderful. It's what they have been doing for 20 years. But obviously they are very good at making computations with them. They're very good at making path finding with them and visibility checks with them and all this kind of things. If you're trying to guess the inside and outside of a building, game algorithms is the way to go. If you want to actually build a building, you have to use DWG. All the architects in the world are using AutoCAD whether we like it or not. As well as the rest of the world in GIS who are not in the FOSFIG, they use Esri. Architects use Autodesk. That's it. With obviously notable exceptions, but a lot of people just use that. And you cannot, it's very, very hard to go to an architect and say give me something that is not an AutoCAD file. If you want to sell stuff which is connected to the internet, go for BIM, absolutely. Just make sure that your stuff is not compatible with anybody else. And if you want to try and be good at everything and fail at everything, you use IndoorGML. So that's all. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you! Are you an agreement by Joe Krubber? Yes? Who is an agreement by an agreement, by Joe Krubber.لب necks of course. I wanted an agreement by geworden Excuse me. In the end, your conclusion was rather, was a dark outlook, it seemed like. But wouldn't you have any, any brighter outlook? Is, would you think in a couple of, because 2014 is like yesterday. So might not be that much time to, to become this standard. Could it be anything in the future that works better like that? I'm not really sure. Really. I'm not optimistic about this. We handle building data every day of my company and it's a mess. Right now it's a mess. I don't see any solution, any easy solution right out of the door. Right. I have also sold indoor open stream map. I don't think it's there yet. It's very tightly coupled to indoor GML. The future is going to be AutoCAD more and more. Because if you have built a building in the Western world, that is to, that is an important remark. If you have built a building in the Western world with plants and architects, the building is going to have AutoCAD files for it. So how can we fix AutoCAD files not serving the purposes that we want? That's a question I don't have the answer for. We can try to process those files and extract more and more information and make it look like a video game, actually. That's actually something that we have joked about in my office. But it's not a joke. Video games are absolutely awesome. I wish, I really, really wish that architects would care for data consistency, but they don't. Architects care about the final map printed in that A1 sheet of paper looks good. They don't care for anything else. Right now, architects don't realize that the data they do, which is a file, not a piece of paper, that data can't have for their users. They just do the job, send them up, get paid, it's over. They don't think that if you open up the data and if you care for the quality of the data, other people can have brighter ideas of what to do with the data. So the architect world doesn't have that mindset yet. And if the people trying to hit that mindset are selling beam formats, so you should care for the semantics of your building, but in my specific format for my specific set of devices. This is going to take time. Okay. I can comment this architect world worked with them lately. At least like 10% of architects are working in beam nowadays. They are not using AutoCats. They are using Gravit, for example, and for data exchange they are using IFC models. I think in Spain and in some countries there are standards for IFCs, which is kind of DXF for beam models. So do you have experiences working with those? Actually no. In my company, we haven't yet had a client which has this kind of format, unfortunately. I would love to have a look, but I don't have any firsthand experience in it. That could be a future, not only for Internet of Things, but just for architecture, what makes sense because the DXF AutoCat formats are just drawings. But architects are understanding. They need the GIS also, and GIS for buildings is a beam. I'm not convinced yet that BIM is a way to go. I'm not sure. I haven't seen that. The people pushing for BIM are selling domotics and are selling some kind of automatism. They are not caring for the kind of unexpected applications of technology that we open source people care about. So I don't have to wait and see. I don't have to wait and see. I'm sorry if I'm pessimistic about this, but that's my point of view. Well, I think we can give you another round of applause.
look at the data model for this game, this is data format is just the same raster, but with screenshot of a very old editor. This is the kind really user-friendly. This is one of the most those sectors in sub-sectors. The big algorithmic of the bridge at the same time from the same good. It's still not perfect AI, because you have the renderer. Or in this case, mapping, creating rendering of buildings. Whenever you see a new beam will model a building in a very different trying to make any use of the things of the wonderful at handling indoor spaces. They're absolutely wonderful. It's what they have been files and extract more and more information and mindset are selling beam formats, so you should my specific format for my specific set of pushing for BIM are selling domotics and are