GraphGIS, Bringing Spatial Functionalities To NoSQL Graph Databases
CC Attribution - NonCommercial - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Houbie, Frédéric (Geomatys)
Heurteaux, Vincent (Geomatys)
Driven by the major players in of the Web like Google, Facebook, Twitter, NoSQL databases quickly gained real legitimacy in handling important data volumetry. With a first concept of key-value, NoSQL databases have quickly evolve to meet a recurring relationships between entities or documents. Graph / document paradigm provides flexibility that facilitates the representation of the real world. Beyond the representation of information of social networks, this data model fits very well to the problem of Geo Information, its variety of data models and the interconnections between them. The emergence of cloud computing and the needs driven by the Semantic Web have led publishers of geospatial solutions to consider other ways than those currently used to store and process GIS information. It is in this perspective that Geomatys has developed GraphGIS, a spatial cartridge for OrientDB, the Graph oriented NoSQL database. This solution provides support of geographic Vector, Raster and Sensor data, in multiple dimensions and their associated metadata.
 you where we were doing I would say database software so list reports list reports really boring stuff and then in 2002 I joined a company so I'm from Belgium I joined a small company called Ionic software which in their history have been acquired by Erdas then by Integrauff so I've been working for 10 years in commercial JIS company and then beginning of this year I've changed and I've joined Geometis it's a company located in south of France nice place and they have a lot of components open-source components and they are building solutions mainly for scientific domain and industrial customers so it's it's a set of open-source component like geo API geo toolkit constellation and we have a set of solutions based on those components started also in 2005 so at the time I was still in Ionic I've worked a lot for DOGC and for ISO mainly for all cataloging and metadata working groups I've been chairing some groups I've been the editors of some specification and since 2010 I'm also a member of the OTC architecture board so that's that's more or less my my background so what is a special database I won't explain you really what is special database I suppose you know it but the kind of information that you would like to store into database that could be look especially located are for example bars or beer location where you have simply position latitude longitude or you can have also box and all this kind of information do not really require what we call a special database many database can store numeric values and you can do simple operation on those on those information like finding where is the point compared to my position or things like this but when you are dealing with more complex information more complex shapes or more complex discovery operations you need a specific structure in your database so a specific way of storing the information and a specific way of doing the query on this information and to have efficient queries you need to build some specific indexes and that's where you really need a special database so on the market what are the solutions that exist for special database of course oracle post GIS special light but for no sequel database there are not a lot of I would say real special solutions Neo4j, CoachDB and MongoDB have some special extension where you can store some geometries you can do some sort of filtering on them but it's not it was not as I would say as powerful as we were looking for so for that reason we decided to think about a component that could be plugged as a cartridge on more or less any database any storage and what what was required if you have a no sequel database you need to define a special model for storing your information some operations on those special information and index those information to have efficient discovery so we needed to find a way to build those components and be able to plug them into no sequel components so we build those components those architecture and then we add also to define what kind of geometry we would like to support so for this we use JTS which is a well-known library and we decided to support all the JTS object all the JTS geometries which is already far more complex than simply a point or a box then we needed to to define a set of operations so either we looked at other special database and copied the operation names to have a kind of compatibility or we looked at what exists as a standard for those special operations and those special extension and we decided to use an ISO standard so SQLMM which have a specific part about special operations so this is an ISO standard that defines the list of methods and functions that you can apply on geographic geometry object so you have a set of transformation operation and functions to transform from WKB from simple text from JML to a geometry object and you have also a set of methods that you can apply to your geometry so to do some discovery about intersect distance between two points or two objects to check if an object is in another object or contains and I think like this so all those methods have a standardized name which means that anyone who would like to implement the same ISO standard would have the same query language the third component is the index the spatial index and for this you have a lot of different spatial index that you can you can do we decided after some comparisons and some implementation to implement the Hilbert R3 index so it's based on the Hilbert curves it's a bit more slower for insertion but it's really faster for retrieval of information if I have internet access I can show you a curve next we had to decide on which no SQL database we will do the I would say the test on which one we would try to plug our cartridge and there you have a lot of choice currently there are more than 150 different no SQL databases there are different paradigm that exists for no SQL databases we had to choose one which match I would say the geospatial requirement and we really liked the graph model because life is can always be represented as a graph of concept of components but the document model was also really matching for example all the document that you can have in geospatial domain like metadata the files things like this so we decided to check in the multi-model databases if there was one was using both the graph and document providing and orient db was one was implementing those two paradigm and we start playing with it we were in contact with the CEO of this the company that build orient db and they were interested in this this cartridge so we use it because it's a mix of graph and document it's also really fast it's amazing how fast it can be and also it's it's a no SQL so not only SQL there is the SQL layer that you can use to query your database so it's not a complete change from a relational model so someone who is using post GIS for example can easily switch to orient db with a special cartridge change is really small and also it can be used in embedded database which is also useful for mobile and things like this so we took the orient db project we modified it a bit to allow pluggable components so we could plug our data cartridge so we had some development to do on it we collaborated a lot so someone from the company is a committer now on orient db which is which is interesting for for for us because our work can go into the project and of course it's interesting for them also to have someone on board who manage all the spatial domain so what we did with the SQL we modified the code and all the parser layer to allow passing SQL statement with different operations and developed this kind of pluggable adapter to support just spatial function and that's the kind of query that you can do on a no SQL database or in db with the special cartridge so you can insert geometry using the operation to create your point your polygon your line things like this and the query is really like what you are doing in post GIS for example so you do select statements and in the where close you can use the different methods that you can apply on the geometry object the geometry are stored in database using wkb and now indexed on a file so the indexed is not stored in the database in the graph database at the beginning we tried to use the graph database also to store the index which was in some use case interesting for example when you have to insert a node you do not have to rebuild all the list you simply have to insert the node between two other one which is in a graph is pretty efficient but for some other part of what it was more difficult and so we decided to put it away from the graph model other kind of stuff you can do you have the Java API also in orient db means that using Java you can build your own representation of geometry here you have three samples so wkb jml and wkb for example and you can easily execute SQL command using the Java language on orient db to insert geometry into the database of course we also support the coordinate transformation so you can store your geometry in any SRS in the database and you can transform coordinates we also have our EPSG database in the graph so we use it also to do the transformation yes other kind of queries so it's for discovery and using method for example to do a union or to calculate the distance between two points so it's really like like post-GIS it's more or less the same but it's a no-SQL database so it means that you have all the the advantages of a no-SQL database for deployment cluster deployment and things like this this is the list of operation that you can apply on your on your geometries and so after having built this this components we had to select one use case to test it we had a list of use cases that we could do or that we would like to do and we we test it on different use case for example the first one we tried is to store raster in the database so following the ISO 19123 coverage model we store the raster into the database which is pretty useful also for the pyramids that are created you have also a pretty efficient raster database using this as I've said the epsg database also 1911 is stored into this graph database which is easy to embed into an application and easy to retrieve transformation coordinate transformation operations as I've said I've been working with metadata and catalog for why now and I've implemented several catalogs in my previous companies and always metadata are a set of documents and they are all related to each other if you take the the big picture of what can be done in the GIS and I've been involved mainly in Earth observation domain you have a set of concept that can be stored into a catalog or registry and that you always need to to link together and that you would like to retrieve based on on some other criteria so for example the big picture is you have data set so it can be a subsurface and product can be vector anything like this you have service which usually publish those data set you have collection of data set also goes that the set series you have rights on those concept you have acquisitions of those data set that can be either satellite or in-situ sensors things like this you have rendering of those data set either great coverage or vector data you need to render them then you have some portfolio rule that you have to store or define somewhere and more and more you define more semantic because people are trying to be more accurate in the description of the metadata so it's not simply now full text people are using more and more ontologies and things like this to describe the metadata so all those concepts are interesting to have in a central catalog or central database and all those concept are linked together so that asset is acquired by a sensor that asset is gathered into collection is published through a service collection are also published through service all of them can be portrayed they have also rights that you need to manage on the data set on the service and of course semantic can be added to any other concept so here you really see it's a graph it's a graph of object and I've implemented those kind of concept into relational database and you always come into the problem on how to normalize this structure into relational database if you're playing with a graph and document database it's more natural you do not have to break structure you keep it as it is and you can traverse your graph to find whatever you want coming from whatever you are so it's really really interesting use case and when you are dealing about semantic of course link data is just a step beyond this is really a graph is dbp here and you see that graph is really a natural model for storing those kind of information the last use case which was interesting is open street map data open street map model is really a graph you have note that relates to way you have way that relates to relation and when you download for example the osm row data it's really a graph of object so usually people take those data transform them into a relational database so they lose the the original structure so what we did to to be able to do some analysis on those data is that we put osm data directly into the graph database without breaking the original model so we keep the structure and I will I will show you what what can be done okay so this is a simple application of viewer it's not optimized for visualization it's simply a data viewer this layer is the osm tile so here we connected to the tile server of osm and retrieved the map if I hide this one so what I have on my laptop is a graph database where we have stored the osm data as it is using the same graph model and I'm retrieving the data as a graph and I'm applying SLD rendering on the fly so it's vector data with SLD rendering directly from the database so you will see you can find it it's pretty slow but I would say that even with retrieving all this information as the original model is pretty fast so there is no optimization it's simply taking the graph model of osm applying rendering so it means that the purpose is not for display because if you zoom out you can see it can be pretty slow because you are retrieving a lot of information but the purpose is to show that keeping the original model of osm you can do data analysis after which is pretty interesting and this is using the graph database it's not so slow okay so just disclaimer to be honest so the purpose is not to show you how far it is or it's not just to say that for data analysis it's really interesting so what we've done on our RionDB as I've said we have improved the component to accept plugins because we did not want to break the original structure and put our components everywhere we wanted to have a component where you simply plug this spatial data cartridge in it we propose it as a get up for currently so RionDB is working on the next release and we will work to align for the next release pretty soon and so the graph.js cartridge has been developed as a DB agnostic and in the title of the presentation I put for graph database between bracket because this could be applied to not graph database also the roadmap I would say of graph.js is integrated with future version of RionDB work on the query engine for big data management because big data is is really it's really big here we have done some tests with osm on some countries if we want to load it on the full world it's a bit more complex so we need to optimize also the query part for this we would like to test this cartridge on other no SQL database other candidates it could be useful to check if it works or what has to be adapted on those components to plug this cartridge in it and also validate the deployment in cluster because that's one of the advantage of those no SQL database that it can be deployed easily in clusters and to for example do some just spatial sharding to have more performances thank you very much I must admit that the beginning it was really hard we had at the beginning to change many parts because it was not so stable it was not done for being extended so we had a lot of work to do and that's the reason why we asked to become a committer into the project because it was a lot of things to change but it was useful for them also but yes you're right it was not as easy as it could have been and sorry one quick other one the OSM database have you got any use cases of where you get value by walking the graph rather than a traditional query I would say not yet the purpose of OSM was because it's a big data use case is the amount of information as I've said metadata is interesting but you never reach number of metadata that you have in OSM data so OSM was mostly to have a large data set of concept to test the database as I said for the metadata yes it's useful it's useful to traverse the graph because you have for example if you would like if I take the slide you have this structure and the typical use case is I would like a service that provide data acquired by let's say spot 5 or acquired by a sensor which have a resolution less than this you do not have always this information to dataset itself so you need to traverse the graph from the service to the data to the sensor because you have to go to the last node to find information what's the name of the project in GitHub? OriandDB? right now it's a for-procoder for OriandDB if you have to search for an OriandDB project there is a for-procoder to make OriandDB a gable okay and then right now we are discussing with Luca Gaudi the leader of the project to integrate this work on the next version but right now the discussions are how we bring this big checkup code on the 107 version of the 2.0 because this is a huge change we are all the SQL models it's more it's more performance but there is a lot of change that the team doesn't know what's all they have to have a deeper look at the code and exactly how it works this is very impressive how many of you were working on this project? for the folder special package free or for people for defense of our workload just to check that I understood correctly you mentioned geospatial sharp I mean that next year it's on one chart some other date is there and it's on the other
 you  where we were doing I would say database software so list reports list reports  really boring stuff and then in 2002 I joined a company so I'm from Belgium I  joined a small company called Ionic software which in their history have  been acquired by Erdas then by Integrauff so I've been working for 10  years in commercial JIS company and then beginning of this year I've changed and  I've joined Geometis it's a company located in south of France nice place  and they have a lot of components open-source components and they are  building solutions mainly for scientific domain and industrial customers so it's  it's a set of open-source component like geo API geo toolkit constellation and  we have a set of solutions based on those components started also in 2005 so at  the time I was still in Ionic I've worked a lot for DOGC and for ISO mainly for  all cataloging and metadata working groups I've been chairing some groups I've  been the editors of some specification and since 2010 I'm also a member of the  OTC architecture board so that's that's more or less my my background so what is  a special database I won't explain you really what is special database I suppose  you know it but the kind of information that you would like to store into  database that could be look especially located are for example bars or beer  location where you have simply position latitude longitude or you can have also  box and all this kind of information do not really require what we call a  special database many database can store numeric values and you can do simple  operation on those on those information like finding where is the point compared  to my position or things like this but when you are dealing with more complex  information more complex shapes or more complex discovery operations you need a  specific structure in your database so a specific way of storing the information  and a specific way of doing the query on this information and to have  efficient queries you need to build some specific indexes and that's where you  really need a special database so on the market what are the solutions that  exist for special database of course oracle post GIS special light but for  no sequel database there are not a lot of I would say real special solutions  Neo4j, CoachDB and MongoDB have some special extension where you can store  some geometries you can do some sort of filtering on them but it's not it was not  as I would say as powerful as we were looking for so for that reason we decided  to think about a component that could be plugged as a cartridge on more or less  any database any storage and what what was required if you have a no sequel  database you need to define a special model for storing your information some  operations on those special information and index those information to have  efficient discovery so we needed to find a way to build those components and be  able to plug them into no sequel components so we build those components  those architecture and then we add also to define what kind of geometry we would  like to support so for this we use JTS which is a well-known library and we  decided to support all the JTS object all the JTS geometries which is already  far more complex than simply a point or a box then we needed to to define a set  of operations so either we looked at other special database and copied the  operation names to have a kind of compatibility or we looked at what  exists as a standard for those special operations and those special extension  and we decided to use an ISO standard so SQLMM which have a specific part about  special operations so this is an ISO standard that defines the list of methods  and functions that you can apply on geographic geometry object so you have a  set of transformation operation and functions to transform from WKB from  simple text from JML to a geometry object and you have also a set of methods  that you can apply to your geometry so to do some discovery about intersect  distance between two points or two objects to check if an object is in  another object or contains and I think like this so all those methods have a  standardized name which means that anyone who would like to implement the  same ISO standard would have the same query language the third component is  the index the spatial index and for this you have a lot of different spatial  index that you can you can do we decided after some comparisons and some  implementation to implement the Hilbert R3 index so it's based on the Hilbert  curves it's a bit more slower for insertion but it's really faster for  retrieval of information if I have internet access I can show you a curve  next we had to decide on which no SQL database we will do the I would say the  test on which one we would try to plug our cartridge and there you have a lot  of choice currently there are more than 150 different no SQL databases there are  different paradigm that exists for no SQL databases we had to choose one which  match I would say the geospatial requirement and we really liked the  graph model because life is can always be represented as a graph of concept of  components but the document model was also really matching for example all  the document that you can have in geospatial domain like metadata the  files things like this so we decided to check in the multi-model databases if  there was one was using both the graph and document providing and orient db was  one was implementing those two paradigm and we start playing with it we were in  contact with the CEO of this the company that build orient db and they were  interested in this this cartridge so we use it because it's a mix of graph and  document it's also really fast it's amazing how fast it can be and also it's  it's a no SQL so not only SQL there is the SQL layer that you can use to  query your database so it's not a complete change from a relational model  so someone who is using post GIS for example can easily switch to orient db  with a special cartridge change is really small and also it can be used in  embedded database which is also useful for mobile and things like this so we  took the orient db project we modified it a bit to allow pluggable components so  we could plug our data cartridge so we had some development to do on it we  collaborated a lot so someone from the company is a committer now on orient db  which is which is interesting for for for us because our work can go into the  project and of course it's interesting for them also to have someone on board  who manage all the spatial domain so what we did with the SQL we modified the  code and all the parser layer to allow passing SQL statement with different  operations and developed this kind of pluggable adapter to support just  spatial function and that's the kind of query that you can do on a no SQL  database or in db with the special cartridge so you can insert geometry  using the operation to create your point your polygon your line things like this  and the query is really like what you are doing in post GIS for example so you  do select statements and in the where close you can use the different methods  that you can apply on the geometry object the geometry are stored in  database using wkb and now indexed on a file so the indexed is not stored in  the database in the graph database at the beginning we tried to use the graph  database also to store the index which was in some use case interesting for  example when you have to insert a node you do not have to rebuild all the list  you simply have to insert the node between two other one which is in a  graph is pretty efficient but for some other part of what it was more difficult  and so we decided to put it away from the graph model  other kind of stuff you can do you have the Java API also in orient db means  that using Java you can build your own representation of geometry here you have  three samples so wkb jml and wkb for example and you can easily execute SQL  command using the Java language on orient db to insert geometry into the  database of course we also support the coordinate transformation so you can  store your geometry in any SRS in the database and you can transform  coordinates we also have our EPSG database in the graph so we use it also  to do the transformation  yes other kind of queries so it's for discovery and using method for example  to do a union or to calculate the distance between two points so it's  really like like post-GIS it's more or less the same but it's a no-SQL database  so it means that you have all the the advantages of a no-SQL database for  deployment cluster deployment and things like this this is the list of  operation that you can apply on your on your geometries and so after having  built this this components we had to select one use case to test it we had a  list of use cases that we could do or that we would like to do and we we test  it on different use case for example the first one we tried is to store raster  in the database so following the ISO 19123 coverage model we store the  raster into the database which is pretty useful also for the pyramids that are  created you have also a pretty efficient raster database using this as I've said  the epsg database also 1911 is stored into this graph database which is easy  to embed into an application and easy to retrieve transformation coordinate  transformation operations as I've said I've been working with metadata and  catalog for why now and I've implemented several catalogs in my  previous companies and always metadata are a set of documents and they are all  related to each other if you take the the big picture of what can be done in the  GIS and I've been involved mainly in Earth observation domain you have a set  of concept that can be stored into a catalog or registry and that you always  need to to link together and that you would like to retrieve based on on some  other criteria so for example the big picture is you have data set so it can  be a subsurface and product can be vector anything like this you have service  which usually publish those data set you have collection of data set also goes  that the set series you have rights on those concept you have acquisitions of  those data set that can be either satellite or in-situ sensors things like  this you have rendering of those data set either great coverage or vector data  you need to render them then you have some portfolio rule that you have to  store or define somewhere and more and more you define more semantic because  people are trying to be more accurate in the description of the metadata so it's  not simply now full text people are using more and more ontologies and things  like this to describe the metadata so all those concepts are interesting to  have in a central catalog or central database and all those concept are  linked together so that asset is acquired by a sensor that asset is gathered  into collection is published through a service collection are also published  through service all of them can be portrayed they have also rights that  you need to manage on the data set on the service and of course semantic can be  added to any other concept so here you really see it's a graph it's a graph of  object and I've implemented those kind of concept into relational database and  you always come into the problem on how to normalize this structure into  relational database if you're playing with a graph and document database it's  more natural you do not have to break structure you keep it as it is and you  can traverse your graph to find whatever you want coming from whatever you are  so it's really really interesting use case and when you are dealing about  semantic of course link data is just a step beyond this is really a graph is  dbp here and you see that graph is really a natural model for storing those  kind of information the last use case which was interesting is open street map  data open street map model is really a graph you have note that relates to way  you have way that relates to relation and when you download for example the  osm row data it's really a graph of object so usually people take those  data transform them into a relational database so they lose the the original  structure so what we did to to be able to do some analysis on those data is that  we put osm data directly into the graph database without breaking the original  model so we keep the structure and I will I will show you what what can be done  okay so this is a simple application of viewer it's not optimized for  visualization it's simply a data viewer this layer is the osm tile so here we  connected to the tile server of osm and retrieved the map if I hide this one so  what I have on my laptop is a graph database where we have stored the osm  data as it is using the same graph model and I'm retrieving the data as a graph  and I'm applying SLD rendering on the fly so it's vector data with SLD rendering  directly from the database so you will see you can find it it's pretty slow but  I would say that even with retrieving all this information as the original model  is pretty fast so there is no optimization it's simply taking the  graph model of osm applying rendering so it means that the purpose is not for  display because if you zoom out you can see it can be pretty slow because you are  retrieving a lot of information but the purpose is to show that keeping the  original model of osm you can do data analysis after which is pretty interesting  and this is using the graph database it's not so slow  okay so just disclaimer to be honest so the purpose is not to show you how far  it is or it's not just to say that for data analysis it's really interesting  so what we've done on our RionDB as I've said we have improved the component to  accept plugins because we did not want to break the original structure and put  our components everywhere we wanted to have a component where you simply plug  this spatial data cartridge in it we propose it as a get up for currently so  RionDB is working on the next release and we will work to align for the next  release pretty soon and so the graph.js cartridge has been developed as a  DB agnostic and in the title of the presentation I put for graph database  between bracket because this could be applied to not graph database also the  roadmap I would say of graph.js is integrated with future version of RionDB  work on the query engine for big data management because big data is is  really it's really big here we have done some tests with osm on some countries if  we want to load it on the full world it's a bit more complex so we need to  optimize also the query part for this we would like to test this cartridge on  other no SQL database other candidates it could be useful to check if it works  or what has to be adapted on those components to plug this cartridge in it  and also validate the deployment in cluster because that's one of the  advantage of those no SQL database that it can be deployed easily in clusters  and to for example do some just spatial sharding to have more performances  thank you very much  I must admit that the beginning it was really hard we had at the beginning to  change many parts because it was not so stable it was not done for being extended  so we had a lot of work to do and that's the reason why we asked to become a  committer into the project because it was a lot of things to change but it was  useful for them also but yes you're right it was not as easy as it could have been  and sorry one quick other one the OSM database have you got any use cases of  where you get value by walking the graph rather than a traditional query  I would say not yet the purpose of OSM was because it's a big data use case is  the amount of information as I've said metadata is interesting but you never  reach number of metadata that you have in OSM data so OSM was mostly to have a  large data set of concept to test the database  as I said for the metadata yes it's useful it's useful to traverse the  graph because you have for example if you would like if I take the slide you  have this structure and the typical use case is I would like a service that  provide data acquired by let's say spot 5 or acquired by a sensor which have a  resolution less than this you do not have always this information to dataset  itself so you need to traverse the graph from the service to the data to the  sensor because you have to go to the last node to find information  what's the name of the project in GitHub? OriandDB?  right now it's a for-procoder for OriandDB if you have to search for an OriandDB project there is a for-procoder to make OriandDB a gable  okay and then right now we are discussing with Luca Gaudi the leader of the project to integrate this work on the next version  but right now the discussions are how we bring this big checkup code on the 107 version of the 2.0 because this is a huge change  we are all the SQL models it's more it's more performance but there is a lot of change that the team doesn't know what's all they have to have a deeper look at the code and exactly how it works  this is very impressive how many of you were working on this project?  for the folder special package free or for people  for defense of our workload  just to check that I understood correctly you mentioned geospatial sharp  I mean that next year it's on one chart some other date is there and it's on the other
Frederic_Houbie___GraphGIS_Bringing_spatial_functionalities_to_nosql_graph_databases__1080p__0_731.png Frederic_Houbie___GraphGIS_Bringing_spatial_functionalities_to_nosql_graph_databases__1080p__732_1283.png Frederic_Houbie___GraphGIS_Bringing_spatial_functionalities_to_nosql_graph_databases__1080p__1284_2951.png Frederic_Houbie___GraphGIS_Bringing_spatial_functionalities_to_nosql_graph_databases__1080p__2952_3155.png Frederic_Houbie___GraphGIS_Bringing_spatial_functionalities_to_nosql_graph_databases__1080p__3156_3203.png Frederic_Houbie___GraphGIS_Bringing_spatial_functionalities_to_nosql_graph_databases__1080p__3204_3251.png Frederic_Houbie___GraphGIS_Bringing_spatial_functionalities_to_nosql_graph_databases__1080p__3252_3719.png Frederic_Houbie___GraphGIS_Bringing_spatial_functionalities_to_nosql_graph_databases__1080p__3720_6383.png Frederic_Houbie___GraphGIS_Bringing_spatial_functionalities_to_nosql_graph_databases__1080p__6384_6503.png Frederic_Houbie___GraphGIS_Bringing_spatial_functionalities_to_nosql_graph_databases__1080p__6504_6635.png Frederic_Houbie___GraphGIS_Bringing_spatial_functionalities_to_nosql_graph_databases__1080p__6636_6755.png Frederic_Houbie___GraphGIS_Bringing_spatial_functionalities_to_nosql_graph_databases__1080p__6756_7547.png Frederic_Houbie___GraphGIS_Bringing_spatial_functionalities_to_nosql_graph_databases__1080p__7548_7751.png Frederic_Houbie___GraphGIS_Bringing_spatial_functionalities_to_nosql_graph_databases__1080p__7752_7811.png Frederic_Houbie___GraphGIS_Bringing_spatial_functionalities_to_nosql_graph_databases__1080p__7812_8063.png Frederic_Houbie___GraphGIS_Bringing_spatial_functionalities_to_nosql_graph_databases__1080p__8064_8135.png Frederic_Houbie___GraphGIS_Bringing_spatial_functionalities_to_nosql_graph_databases__1080p__8136_8183.png Frederic_Houbie___GraphGIS_Bringing_spatial_functionalities_to_nosql_graph_databases__1080p__8184_8291.png Frederic_Houbie___GraphGIS_Bringing_spatial_functionalities_to_nosql_graph_databases__1080p__8292_8387.png Frederic_Houbie___GraphGIS_Bringing_spatial_functionalities_to_nosql_graph_databases__1080p__8388_8723.png Frederic_Houbie___GraphGIS_Bringing_spatial_functionalities_to_nosql_graph_databases__1080p__8724_10055.png Frederic_Houbie___GraphGIS_Bringing_spatial_functionalities_to_nosql_graph_databases__1080p__10056_10139.png Frederic_Houbie___GraphGIS_Bringing_spatial_functionalities_to_nosql_graph_databases__1080p__10140_10523.png Frederic_Houbie___GraphGIS_Bringing_spatial_functionalities_to_nosql_graph_databases__1080p__10524_10847.png Frederic_Houbie___GraphGIS_Bringing_spatial_functionalities_to_nosql_graph_databases__1080p__10848_10895.png Frederic_Houbie___GraphGIS_Bringing_spatial_functionalities_to_nosql_graph_databases__1080p__10896_11171.png Frederic_Houbie___GraphGIS_Bringing_spatial_functionalities_to_nosql_graph_databases__1080p__11172_11543.png Frederic_Houbie___GraphGIS_Bringing_spatial_functionalities_to_nosql_graph_databases__1080p__11544_13475.png Frederic_Houbie___GraphGIS_Bringing_spatial_functionalities_to_nosql_graph_databases__1080p__13476_14759.png Frederic_Houbie___GraphGIS_Bringing_spatial_functionalities_to_nosql_graph_databases__1080p__14760_21383.png Frederic_Houbie___GraphGIS_Bringing_spatial_functionalities_to_nosql_graph_databases__1080p__21384_29111.png Frederic_Houbie___GraphGIS_Bringing_spatial_functionalities_to_nosql_graph_databases__1080p__29112_29747.png Frederic_Houbie___GraphGIS_Bringing_spatial_functionalities_to_nosql_graph_databases__1080p__29748_30383.png Frederic_Houbie___GraphGIS_Bringing_spatial_functionalities_to_nosql_graph_databases__1080p__30384_30575.png Frederic_Houbie___GraphGIS_Bringing_spatial_functionalities_to_nosql_graph_databases__1080p__30576_32951.png Frederic_Houbie___GraphGIS_Bringing_spatial_functionalities_to_nosql_graph_databases__1080p__32952_38268.png