Redefining Geospatial data versioning: The GeoGit approach
CC Attribution 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 purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Marin, Juan
Everyone working with geospatial data eventually faces the problem of managing their information and assets as they change over time. Versioning of geospatial data has been an issue for any workflow that involves more than one individual. Questions like who changed what and when become hard to answer, and while versioning approaches have existed for a while, they are cumbersome to use and utilize old paradigms. GeoGit takes concepts and lessons learned from the open source programming world and applies them to management of geospatial information, allowing better and decentralized management of versioned data and enabling new and innovative workflows for collaboration. In this 2 hour workshop, we'll walk through core procedures in managing version history and inter-operating with preexisting spatial software tools.
 The thing that we could probably all agree on is that one of the reasons you version data is because keeping history of that information is very important. And here are a couple of examples that I like to talk about. On the left we have a map of the former Yugoslavia country and right now we have six sovereign nations. That's a result of the war in the 90s. The map on the right is also kind of striking. This is the ethnic distribution of Bosnia before and after the war. So it's important to keep track of these changes, be those political, physical, natural, in the way we represent our information. And that's what a lot of people think about when they think about versioning information. They think about historical information. But that's not the only reason we may want to version information. We create versions of data for many different reasons. People might be collaborating on the same dataset concurrently, for instance, or you may want to see a different view of the world, of reality, and you may want to prove a point based on that. We argue that we need better tools for this. The state of the art in the industry is good, but there are new models, new ways of working that require new tools, and we like to talk about those today. So the other way looks something like this. You have a lot of people that are trying to collaborate. They are part of a team. Usually they work with data. They modify data. And what usually ends up happening is that you have groups of people that are collaborating through a big relational database, usually. That's what the versioning happens. Another group of people do something kind of similar, and this other person is left wondering how can I extract some of those changes from those two groups? Maybe not all of them, because I may not be interested in every change that happened, but how can I pick and choose the changes that I'm interested in? Do that in real time and when I want to do it, not when it happens in the database. This kind of workflow becomes a little bit cumbersome with a single point of versioning, which is a database. We can think of it in a new way. You can think of this as a peer-to-peer network. Everyone is exchanging information about their versions, and everyone has a full copy of the history of the data sets. That might sound like a lot of information, but the way we've solved this with GeoGate is as optimal as it can be, so you're not really copying every, with every version, with every new version, you're not copying a lot of data. You're just copying the changes that happen to that data. So it can become fairly efficient, and we can all exchange different pieces of information with each other. There is no single central point where the versioning happens. Everyone is participating in the versioning. We can exchange information with our peers. We can also institute some sort of centralized versioning system that becomes an organizational decision, not a technical limitation. We argue that this is better for many reasons, and I just like to offer these three. First of all, it doesn't have a single point of failure. These days with relational databases, we've gotten really good at guaranteeing uptime and fault tolerance, et cetera, but it can still go down. You can still find that a data center goes down, that a system is not available, and in that case, you can't work. You can't just connect to somewhere, do your versioning, keep adding versions, et cetera. So with this distributed model, we don't have a single point of failure. You can still keep adding versions to your data locally. There is no single source of truth for just spatial information with this model. This actually kind of scares a lot of people and is a little bit controversial because we hear a lot about authoritative data sets and people owning information and making the canonical copy of something, but the reality of it is that people just, data wants to be free. Data wants to be copied, it wants to be used for different purposes. And once that happens, I probably want to create my own version of that data for whatever reason. My copy of the road network might be different from the transportation planning department. So it's good that we can actually do this and keep track of the provenance of the information. And these two aspects actually result in a better model for sharing and collaboration on spatial information. So our approach to these problems and to this idea is a project called GeoGet. It's an open source project, has a BSD license. It's built in Java. And that's the website in case people want to check it out, take a look. There's a lot of documentation. You can download the software. There's a couple of tutorials and workshops that you can go through and take a look. It is part of the location tech working group for the Eclipse Foundation. We're really excited about that. We're going through that process now. And this is with the intention to provide a tool that's in a vendor neutral space. We would like to see this concept grow. And we would like to see different implementations on top of different software. So how many of you are developers? How many developers here? Okay, quite a few. So this is the easy audience. How many have worked with Git? All right, still quite a few. So GeoGet actually follows the Git model quite closely. And there's a few new concepts that you have to be aware of. And as I'll show later, you don't have to know this very precisely by using other types of tools. But if you're working with a low-level command line interface, you should know at least what this means. So usually we have data, spatial data somewhere. That's in the form of files. They could be shape files, GIA JSON files, et cetera. Usually also you'll have something like a spatial database, be that POST-YS or Oracle spatial, et cetera. And what GeoGet does is it keeps track of the changes that you made in this data sets. And in order to do that, it has to import that information into the work, what we call the working tree. This is where you're going to be modifying information. And then there's a sort of a two-stage saving mechanism where first you add the information to the staging area. At that point, you're flagging that information as version. And GeoGet will keep track of those changes. And then whenever you're ready to do what is called a commit, a new point in the history gets created. So that's a new version, basically, on your repository. As we saw from the previous slides, the nice thing about this model is that it can be remote. So there's also a few operations to work with remote repositories. You can push changes to a remote repository or pull changes from remote repositories and keep all these data sets in sync, basically. So the power of this model is enabled by these concepts of branching and merging, which may sound alien to GIS analysts or to GIS people, but it's actually fairly simple. The idea is we have a main line of a main version with its history points that's represented on the left side by that master branch. That's my canonical copy of my data. And whenever I want to make a change, whenever someone wants to make a change, what they do is they create a branch. A branch is a divergence in the history of that information, of that data set. And I can make changes in that branch. I am isolated from what happens on master. Master actually can get new edits, new changes, so history keeps advancing and the versioning keeps advancing. And whenever I'm ready to bring these changes on this branch back to master, I do what is called a merge. At that point, GeoGit will detect if there are any conflicts with those edits, because I may have modified a polygon that someone else also modified or maybe deleted or maybe they changed the attributes. So GeoGit will tell you what conflicts you may have and you have to solve those. GeoGit doesn't solve them automatically, this tool is not designed to do that because sometimes you don't know. Sometimes it requires human innovation. We could always add some scripting on top of this. That's certainly possible, but GeoGit will not make a decision for you on which of the two copies is the good one. That's something that you have to implement on a workflow. So I get asked this question a lot, like a lot of people say, okay, why don't you just use Git with GeoJSON files? And it's a good solution if you are willing to cope with the limitations of that format. GeoJSON is a great format for representing geospatial information on a web map, but it's not really a format that will support versioning for large datasets. Git itself wasn't built with large binary files in mind. So we did try to actually implement GeoGit on top of Git directly and this just didn't scale, didn't work. And also this workflow has pretty big gaps with integration with other tools. There's no integration with desktop tools, other GIS servers, etc. So by all means, if you can use this, do it because the Git haptos are pretty awesome and they can actually help you with your workflow, but we're trying to add to that idea by supporting bigger files and more specialized workflows. So why do this? Why would we want to version information and why do we want to keep those versions around? I'm going to offer three. There are many more, but I'm just going to offer three here today. The first one is a classical GIS operation where you're studying different alternatives for, let's say, a road that's being built and you want to study their, maybe their environmental impact or something like that. So you may want to keep those versions around. You may want to run models on those versions separately and it's very easy to change from one version to the other because that's just an operation that's called a checkout and they all live in the same repository. What usually ends up happening is that when you're done with this process, you throw the alternatives that didn't get chosen. You throw them away or you store them somewhere. With this model, they can just live on a branch and you can access them at any time. Another classical example of why you would want to do versioning is crowdsourcing. It's a hot topic these days. A lot of people want to do this. It presents some challenges for your IT infrastructure and your systems people. They will probably freak out when you tell them that you're going to open up a database and that people are going to write to it. That means that they'll have to implement a lot of safeguards and security protocols and there's always a concern that that database is going to be corrupted, et cetera. So an easy way to approach this problem is to just offer a branch for crowdsourcing. And someone or some process can actually pick and choose whatever changes are good for your production-based database and bring those into your organization. The other one is OpenStreetMap. How many people have worked with OpenStreetMap data? Quite a few. OpenStreetMap is a worldwide crowdsourced vector street map. It's very detailed. Sometimes it's better than the commercial providers in some areas. And a lot of people want to use it within their organization, which is something that sounds like a no-brainer, but it's actually not that easy. So with GeoGrid, this is what you do to actually ingest OSM data into your GeoGrid repository. It's just a couple of commands, as you can see here. The first one is just downloading a section of OSM. I'm just passing a bounding box. And that's actually the greater London area. And it'll just click that area and download everything. At that point, I create a new repository. And everything that I do to it is going to be versioned. So I can keep track of the changes that I do locally to my OSM data. But I also want to keep track of what the community keeps doing to the data set. I want to get the updates that the crowd is doing into OSM. So that's what the second command allows me to do. It'll just bring in whatever changes happen to OSM, calculate the differences, and put those into my GeoGrid repository. And actually, if there are some conflicts between the changes that I did and the ones that the crowd did, it'll also tell me, and I'll decide what to do with those. We can actually filter as well. This is a mapping file. It follows the Overpass API language. So I can not only get everything in a certain area, but I can also say, maybe I'm only interested in the highways or only the bridges or something like that. And finally, we can also contribute back to OSM. If we create new data in GeoGrid, there's an export command that will allow me to produce a PDF file that I can then take into an OSM editor and put it into the crowd source map, the public map. So it's a nice workflow for using and also giving back to OSM. So right now, GeoGrid has released a few versions. We just released about a month ago, version 0.8. We're actively working on releasing 0.9. There's a complete command line interface tool that comes with GeoGrid when you download it. I like to say that it's featured complete. By that I mean that it's usable. You can start using it. It's being used in production in some priors like we'll see in the next talk. But we're still working on tweaking things, internal structure, optimizing some operations, performance, et cetera. And we hope to reach 1.0 in a couple months or so. Here are some examples of the command line just to give you a sense of what they look like. A log will show me the commits, the different points of history. The second one is kind of the feature that matters here, which is a geospatial diff. It's not complete because I had to cut the screen, but you can see already there's a poly on there. So it's detecting changes in geography. And I'll show that in a second in the demo. So that's the core GeoGrid project. At Balanced we're working on some additional tools around this core library. We're adding a Python library that would allow you to automate some of these processes in an easier, more accessible language such as Python. We're also implementing a high-performance GeoGrid server that will expose many of these operations through a RESTful API that outputs JSON and GeoJSON, like you see on the right hand side. We are also working on a QGIS plugin. So GIS analysts will be able to access this functionality without touching the command line, without having to know about GeoJSON and those things. We're also adding web components for web mapping applications. And we're also working on supporting larger deployments, larger repositories, performance optimizations, et cetera. And I am going to try to give you a small short demo of some of these things. So resolution is not very good. I apologize for that. But you can get an idea. This is the GeoGrid plugin that we are working on with QGIS. So here you can see, here's the history of my repositories, all the things that I did to those data sets. I'm working with this buildings layer from OSM. This is actually in Ethiopia. So as you can see, I have a Bing layer. It's a bit dark. This is aerial photography, and there's a few buildings that have been digitized already. So this tells me here, I don't know if you can read this, but we are currently in the edits branch. So I created a branch. I'm editing information. And I'm just going to add a few, or maybe one, polygon here. So hopefully the internet works for the base map. And I can do something meaningful. This data is actually currently in a posious database that's running locally. So I'm going to create a polygon here. And forgive me for my lack of precision, but I'm just going to digitize something like this. All right. So I created a new polygon. I click OK. It's a new entry into my database. I'm going to save the edits. And the GeoGrid plugin is going to ask me if I want to import this into the GeoGrid repository to create a new version, which I'll say yes. And it will immediately ask me why. Why did I do this? What's my commit message? What is the operation that I did? So I'm going to add a building. And as you'll see, the list gets updated. This is a new entry into my history list, a new point in my versioning. And it's in my edits branch. So what I'm going to do now is I'm going to actually change my branch. I'm going to go to master. That's my main version branch. You can see that that last commit is not here. And I'm going to merge that from the other branch. And this is one person working on two branches, but you can see where this is going. You can have people collaborating this way and adding changes. So there's my new commit that I just created. The other thing we can do is there's, as I said, a server that we also are working on. So that looks something like this. This is the same repository exposed in the form of several layers. And as you can see, this is a web map display with the same information. And what I'm going to do is I'm going to push these changes to the server so I can view them in a web display. For that, I can just do a sync with the server, which is already configured for this repository. And what it'll do is it'll first pull the changes from the remote repository in case someone else made some changes. And then it's going to push my changes to it. And if that is successful, which it looks like it did, I'm going to redraw this. And you see this polygon just showed up here, which wasn't there before. We also have some tools to kind of see all this history, all this commits, and be able to actually view the changes before and after a commit was made. This one was just one polygon. It's not very interesting. I'll offer you another view that's a bit more complete, which is probably this one. So for instance here, the green ones are polygons that were added. The red ones were deleted. And I think down here is one that was modified, the blue one. So you can see the blue one was just slightly moved. Maybe it wasn't digitized in the right place. So that's what we are working on. GeoGrid and its growing ecosystem. Again, I'd like to stress that we think this is a better model for editing, versioning, and collaboration because of the reasons that I served before. And thank you very much for your time. And I'll be happy to chat with you later if you have any questions or want to know more. Thank you. Thank you.
 The thing that we could probably all agree on is that one of the reasons you version  data is because keeping history of that information is very important.  And here are a couple of examples that I like to talk about.  On the left we have a map of the former Yugoslavia country and right now we have six sovereign  nations.  That's a result of the war in the 90s.  The map on the right is also kind of striking.  This is the ethnic distribution of Bosnia before and after the war.  So it's important to keep track of these changes, be those political, physical, natural, in  the way we represent our information.  And that's what a lot of people think about when they think about versioning information.  They think about historical information.  But that's not the only reason we may want to version information.  We create versions of data for many different reasons.  People might be collaborating on the same dataset concurrently, for instance, or you  may want to see a different view of the world, of reality, and you may want to prove a point  based on that.  We argue that we need better tools for this.  The state of the art in the industry is good, but there are new models, new ways of working  that require new tools, and we like to talk about those today.  So the other way looks something like this.  You have a lot of people that are trying to collaborate.  They are part of a team.  Usually they work with data.  They modify data.  And what usually ends up happening is that you have groups of people that are collaborating  through a big relational database, usually.  That's what the versioning happens.  Another group of people do something kind of similar, and this other person is left  wondering how can I extract some of those changes from those two groups?  Maybe not all of them, because I may not be interested in every change that happened,  but how can I pick and choose the changes that I'm interested in?  Do that in real time and when I want to do it, not when it happens in the database.  This kind of workflow becomes a little bit cumbersome with a single point of versioning,  which is a database.  We can think of it in a new way.  You can think of this as a peer-to-peer network.  Everyone is exchanging information about their versions, and everyone has a full copy  of the history of the data sets.  That might sound like a lot of information, but the way we've solved this with GeoGate  is as optimal as it can be, so you're not really copying every, with every version,  with every new version, you're not copying a lot of data.  You're just copying the changes that happen to that data.  So it can become fairly efficient, and we can all exchange different pieces of information  with each other.  There is no single central point where the versioning happens.  Everyone is participating in the versioning.  We can exchange information with our peers.  We can also institute some sort of centralized versioning system that becomes an organizational  decision, not a technical limitation.  We argue that this is better for many reasons, and I just like to offer these three.  First of all, it doesn't have a single point of failure.  These days with relational databases, we've gotten really good at guaranteeing uptime and  fault tolerance, et cetera, but it can still go down.  You can still find that a data center goes down, that a system is not available, and  in that case, you can't work.  You can't just connect to somewhere, do your versioning, keep adding versions, et cetera.  So with this distributed model, we don't have a single point of failure.  You can still keep adding versions to your data locally.  There is no single source of truth for just spatial information with this model.  This actually kind of scares a lot of people and is a little bit controversial because  we hear a lot about authoritative data sets and people owning information and making the  canonical copy of something, but the reality of it is that people just, data wants to be  free.  Data wants to be copied, it wants to be used for different purposes.  And once that happens, I probably want to create my own version of that data for whatever  reason.  My copy of the road network might be different from the transportation planning department.  So it's good that we can actually do this and keep track of the provenance of the information.  And these two aspects actually result in a better model for sharing and collaboration  on spatial information.  So our approach to these problems and to this idea is a project called GeoGet.  It's an open source project, has a BSD license.  It's built in Java.  And that's the website in case people want to check it out, take a look.  There's a lot of documentation.  You can download the software.  There's a couple of tutorials and workshops that you can go through and take a look.  It is part of the location tech working group for the Eclipse Foundation.  We're really excited about that.  We're going through that process now.  And this is with the intention to provide a tool that's in a vendor neutral space.  We would like to see this concept grow.  And we would like to see different implementations on top of different software.  So how many of you are developers?  How many developers here?  Okay, quite a few.  So this is the easy audience.  How many have worked with Git?  All right, still quite a few.  So GeoGet actually follows the Git model quite closely.  And there's a few new concepts that you have to be aware of.  And as I'll show later, you don't have to know this very precisely by using other types  of tools.  But if you're working with a low-level command line interface, you should know at least what  this means.  So usually we have data, spatial data somewhere.  That's in the form of files.  They could be shape files, GIA JSON files, et cetera.  Usually also you'll have something like a spatial database, be that POST-YS or Oracle  spatial, et cetera.  And what GeoGet does is it keeps track of the changes that you made in this data sets.  And in order to do that, it has to import that information into the work, what we call  the working tree.  This is where you're going to be modifying information.  And then there's a sort of a two-stage saving mechanism where first you add the information  to the staging area.  At that point, you're flagging that information as version.  And GeoGet will keep track of those changes.  And then whenever you're ready to do what is called a commit, a new point in the history  gets created.  So that's a new version, basically, on your repository.  As we saw from the previous slides, the nice thing about this model is that it can be remote.  So there's also a few operations to work with remote repositories.  You can push changes to a remote repository or pull changes from remote repositories and  keep all these data sets in sync, basically.  So the power of this model is enabled by these concepts of branching and merging, which may  sound alien to GIS analysts or to GIS people, but it's actually fairly simple.  The idea is we have a main line of a main version with its history points that's represented  on the left side by that master branch.  That's my canonical copy of my data.  And whenever I want to make a change, whenever someone wants to make a change, what they do  is they create a branch.  A branch is a divergence in the history of that information, of that data set.  And I can make changes in that branch.  I am isolated from what happens on master.  Master actually can get new edits, new changes, so history keeps advancing and the versioning  keeps advancing.  And whenever I'm ready to bring these changes on this branch back to master, I do what is  called a merge.  At that point, GeoGit will detect if there are any conflicts with those edits, because  I may have modified a polygon that someone else also modified or maybe deleted or maybe  they changed the attributes.  So GeoGit will tell you what conflicts you may have and you have to solve those.  GeoGit doesn't solve them automatically, this tool is not designed to do that because sometimes  you don't know.  Sometimes it requires human innovation.  We could always add some scripting on top of this.  That's certainly possible, but GeoGit will not make a decision for you on which of the  two copies is the good one.  That's something that you have to implement on a workflow.  So I get asked this question a lot, like a lot of people say, okay, why don't you just  use Git with GeoJSON files?  And it's a good solution if you are willing to cope with the limitations of that format.  GeoJSON is a great format for representing geospatial information on a web map, but it's  not really a format that will support versioning for large datasets.  Git itself wasn't built with large binary files in mind.  So we did try to actually implement GeoGit on top of Git directly and this just didn't  scale, didn't work.  And also this workflow has pretty big gaps with integration with other tools.  There's no integration with desktop tools, other GIS servers, etc.  So by all means, if you can use this, do it because the Git haptos are pretty awesome  and they can actually help you with your workflow, but we're trying to add to that idea by supporting  bigger files and more specialized workflows.  So why do this?  Why would we want to version information and why do we want to keep those versions around?  I'm going to offer three.  There are many more, but I'm just going to offer three here today.  The first one is a classical GIS operation where you're studying different alternatives  for, let's say, a road that's being built and you want to study their, maybe their environmental  impact or something like that.  So you may want to keep those versions around.  You may want to run models on those versions separately and it's very easy to change from  one version to the other because that's just an operation that's called a checkout and  they all live in the same repository.  What usually ends up happening is that when you're done with this process, you throw the  alternatives that didn't get chosen.  You throw them away or you store them somewhere.  With this model, they can just live on a branch and you can access them at any time.  Another classical example of why you would want to do versioning is crowdsourcing.  It's a hot topic these days.  A lot of people want to do this.  It presents some challenges for your IT infrastructure and your systems people.  They will probably freak out when you tell them that you're going to open up a database  and that people are going to write to it.  That means that they'll have to implement a lot of safeguards and security protocols  and there's always a concern that that database is going to be corrupted, et cetera.  So an easy way to approach this problem is to just offer a branch for crowdsourcing.  And someone or some process can actually pick and choose whatever changes are good for your  production-based database and bring those into your organization.  The other one is OpenStreetMap.  How many people have worked with OpenStreetMap data?  Quite a few.  OpenStreetMap is a worldwide crowdsourced vector street map.  It's very detailed.  Sometimes it's better than the commercial providers in some areas.  And a lot of people want to use it within their organization, which is something that  sounds like a no-brainer, but it's actually not that easy.  So with GeoGrid, this is what you do to actually ingest OSM data into your GeoGrid repository.  It's just a couple of commands, as you can see here.  The first one is just downloading a section of OSM.  I'm just passing a bounding box.  And that's actually the greater London area.  And it'll just click that area and download everything.  At that point, I create a new repository.  And everything that I do to it is going to be versioned.  So I can keep track of the changes that I do locally to my OSM data.  But I also want to keep track of what the community keeps doing to the data set.  I want to get the updates that the crowd is doing into OSM.  So that's what the second command allows me to do.  It'll just bring in whatever changes happen to OSM, calculate the differences, and put  those into my GeoGrid repository.  And actually, if there are some conflicts between the changes that I did and the ones  that the crowd did, it'll also tell me, and I'll decide what to do with those.  We can actually filter as well.  This is a mapping file.  It follows the Overpass API language.  So I can not only get everything in a certain area, but I can also say, maybe I'm only interested  in the highways or only the bridges or something like that.  And finally, we can also contribute back to OSM.  If we create new data in GeoGrid, there's an export command that will allow me to produce  a PDF file that I can then take into an OSM editor and put it into the crowd source map,  the public map.  So it's a nice workflow for using and also giving back to OSM.  So right now, GeoGrid has released a few versions.  We just released about a month ago, version 0.8.  We're actively working on releasing 0.9.  There's a complete command line interface tool that comes with GeoGrid when you download  it.  I like to say that it's featured complete.  By that I mean that it's usable.  You can start using it.  It's being used in production in some priors like we'll see in the next talk.  But we're still working on tweaking things, internal structure, optimizing some operations,  performance, et cetera.  And we hope to reach 1.0 in a couple months or so.  Here are some examples of the command line just to give you a sense of what they look  like.  A log will show me the commits, the different points of history.  The second one is kind of the feature that matters here, which is a geospatial diff.  It's not complete because I had to cut the screen, but you can see already there's a  poly on there.  So it's detecting changes in geography.  And I'll show that in a second in the demo.  So that's the core GeoGrid project.  At Balanced we're working on some additional tools around this core library.  We're adding a Python library that would allow you to automate some of these processes in  an easier, more accessible language such as Python.  We're also implementing a high-performance GeoGrid server that will expose many of these  operations through a RESTful API that outputs JSON and GeoJSON, like you see on the right  hand side.  We are also working on a QGIS plugin.  So GIS analysts will be able to access this functionality without touching the command  line, without having to know about GeoJSON and those things.  We're also adding web components for web mapping applications.  And we're also working on supporting larger deployments, larger repositories, performance  optimizations, et cetera.  And I am going to try to give you a small short demo of some of these things.  So resolution is not very good.  I apologize for that.  But you can get an idea.  This is the GeoGrid plugin that we are working on with QGIS.  So here you can see, here's the history of my repositories, all the things that I did  to those data sets.  I'm working with this buildings layer from OSM.  This is actually in Ethiopia.  So as you can see, I have a Bing layer.  It's a bit dark.  This is aerial photography, and there's a few buildings that have been digitized already.  So this tells me here, I don't know if you can read this, but we are currently in the  edits branch.  So I created a branch.  I'm editing information.  And I'm just going to add a few, or maybe one, polygon here.  So hopefully the internet works for the base map.  And I can do something meaningful.  This data is actually currently in a posious database that's running locally.  So I'm going to create a polygon here.  And forgive me for my lack of precision, but I'm just going to digitize something like  this.  All right.  So I created a new polygon.  I click OK.  It's a new entry into my database.  I'm going to save the edits.  And the GeoGrid plugin is going to ask me if I want to import this into the GeoGrid repository  to create a new version, which I'll say yes.  And it will immediately ask me why.  Why did I do this?  What's my commit message?  What is the operation that I did?  So I'm going to add a building.  And as you'll see, the list gets updated.  This is a new entry into my history list, a new point in my versioning.  And it's in my edits branch.  So what I'm going to do now is I'm going to actually change my branch.  I'm going to go to master.  That's my main version branch.  You can see that that last commit is not here.  And I'm going to merge that from the other branch.  And this is one person working on two branches, but you can see where this is going.  You can have people collaborating this way and adding changes.  So there's my new commit that I just created.  The other thing we can do is there's, as I said, a server that we also are working on.  So that looks something like this.  This is the same repository exposed in the form of several layers.  And as you can see, this is a web map display with the same information.  And what I'm going to do is I'm going to push these changes to the server so I can  view them in a web display.  For that, I can just do a sync with the server, which is already configured for this repository.  And what it'll do is it'll first pull the changes from the remote repository in case  someone else made some changes.  And then it's going to push my changes to it.  And if that is successful, which it looks like it did, I'm going to redraw this.  And you see this polygon just showed up here, which wasn't there before.  We also have some tools to kind of see all this history, all this commits, and be able  to actually view the changes before and after a commit was made.  This one was just one polygon.  It's not very interesting.  I'll offer you another view that's a bit more complete, which is probably this one.  So for instance here, the green ones are polygons that were added.  The red ones were deleted.  And I think down here is one that was modified, the blue one.  So you can see the blue one was just slightly moved.  Maybe it wasn't digitized in the right place.  So that's what we are working on.  GeoGrid and its growing ecosystem.  Again, I'd like to stress that we think this is a better model for editing, versioning,  and collaboration because of the reasons that I served before.  And thank you very much for your time.  And I'll be happy to chat with you later if you have any questions or want to know more.  Thank you.  Thank you.
Redefining_Geospatial_data_versioning__The_GeoGit_approach__720p__0_1451.png Redefining_Geospatial_data_versioning__The_GeoGit_approach__720p__1452_2303.png Redefining_Geospatial_data_versioning__The_GeoGit_approach__720p__2304_3695.png Redefining_Geospatial_data_versioning__The_GeoGit_approach__720p__3696_7559.png Redefining_Geospatial_data_versioning__The_GeoGit_approach__720p__7560_8699.png Redefining_Geospatial_data_versioning__The_GeoGit_approach__720p__8700_9251.png Redefining_Geospatial_data_versioning__The_GeoGit_approach__720p__9252_10607.png Redefining_Geospatial_data_versioning__The_GeoGit_approach__720p__10608_14471.png Redefining_Geospatial_data_versioning__The_GeoGit_approach__720p__14472_16379.png Redefining_Geospatial_data_versioning__The_GeoGit_approach__720p__16380_17771.png Redefining_Geospatial_data_versioning__The_GeoGit_approach__720p__17772_21719.png Redefining_Geospatial_data_versioning__The_GeoGit_approach__720p__21720_23423.png Redefining_Geospatial_data_versioning__The_GeoGit_approach__720p__23424_24083.png Redefining_Geospatial_data_versioning__The_GeoGit_approach__720p__24084_25775.png Redefining_Geospatial_data_versioning__The_GeoGit_approach__720p__25776_28331.png Redefining_Geospatial_data_versioning__The_GeoGit_approach__720p__28332_28631.png Redefining_Geospatial_data_versioning__The_GeoGit_approach__720p__28632_29855.png Redefining_Geospatial_data_versioning__The_GeoGit_approach__720p__29856_31007.png Redefining_Geospatial_data_versioning__The_GeoGit_approach__720p__31008_31091.png Redefining_Geospatial_data_versioning__The_GeoGit_approach__720p__31092_31523.png Redefining_Geospatial_data_versioning__The_GeoGit_approach__720p__31524_31739.png Redefining_Geospatial_data_versioning__The_GeoGit_approach__720p__31740_31799.png Redefining_Geospatial_data_versioning__The_GeoGit_approach__720p__31800_31931.png Redefining_Geospatial_data_versioning__The_GeoGit_approach__720p__31932_32063.png Redefining_Geospatial_data_versioning__The_GeoGit_approach__720p__32064_32123.png Redefining_Geospatial_data_versioning__The_GeoGit_approach__720p__32124_32243.png Redefining_Geospatial_data_versioning__The_GeoGit_approach__720p__32244_32906.png