We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

GIS Migration Paths - Tools and strategies to move to open source GIS

00:00

Formal Metadata

Title
GIS Migration Paths - Tools and strategies to move to open source GIS
Title of Series
Number of Parts
295
Author
Contributors
License
CC Attribution 3.0 Germany:
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.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
This talk highlights the issues that need to be addressed to successfully migrate from a GIS solution based on commercial products to a solution based on open-source software, in particular QGIS. What can be done? Where to start? What are the potential elements to convert? Which strategy to adopt? The talk will try to answer these questions by showing examples and lesson learned from successful Migrations. By presenting ad-hoc open source tools developed to solve specific problems and explaining how a migration can be tackled in cases where there are currently no specific tools we want to give you all the information needed to take informed decisions.
Keywords
Software developerInformation technology consultingStudent's t-testMereologyJava appletSpeech synthesisSpecial unitary groupOpen sourceQueue (abstract data type)Product (business)Lecture/Conference
Open sourceOpen setStack (abstract data type)Heegaard splittingMereologyExterior algebraPresentation of a groupOpen sourceSoftware developerSoftwareSound effectStrategy gameCondition numberPrisoner's dilemmaComputer animation
Open setOpen sourceComputer architectureHuman migrationComputer animation
Mobile WebServer (computing)Open setInformation securitySoftwareStaff (military)Strategy gameSoftwareMultiplication signExterior algebraHuman migrationScripting languageDatabaseMathematical analysisSource codeMathematicsPhysical systemServer (computing)Web 2.0MappingMereologyReverse engineeringStaff (military)InformationOpen sourceMobile WebCodeData conversionOpen setBit rateInteractive televisionDemosceneData storage deviceWater vaporCore dumpOrder (biology)Computer animation
File formatSoftwareStaff (military)Strategy gameLine (geometry)Point (geometry)PolygonLibrary (computing)Computer fileType theoryData conversionAlgorithmScripting languageProcess (computing)InformationSoftware developerData storage deviceQueue (abstract data type)Open sourceResultantDemosceneSoftwareTouchscreenProjective planeTheory of relativityProduct (business)Data structureSystem administratorDirected graphLibrary (computing)MereologyBinary codeOffice suiteLie groupWeightGroup actionLine (geometry)Multiplication signPlanningPoint (geometry)Data conversionBinary fileSymbol tableComputer architectureReverse engineeringComplete metric spaceExtension (kinesiology)UsabilityScripting languageFile formatMedical imagingPhysical system
Type theoryData conversionScripting languageAlgorithmOpen setProjective planeVideoconferencingComputer animation
HypermediaExecution unitMotion captureComputer iconVideo game consoleMaxima and minimaPersonal identification numberConvex hullData conversionPlanningHill differential equationEmailMenu (computing)MereologyLibrary (computing)Arithmetic meanData managementAlgorithmParameter (computer programming)Symbol tableComputer fileComputer animation
TouchscreenOpen setHuman migrationComputer animation
Level (video gaming)WebsiteMultiplication signSoftware developerGoodness of fitResultantCodeOpen sourceProjective planeLink (knot theory)Software repositoryMathematical analysisTraffic reportingArithmetic progressionSimilarity (geometry)Codierung <Programmierung>Object (grammar)Lecture/Conference
Transcript: English(auto-generated)
My name is Mario Barancini. I work as a developer mostly in Python and Java for a small Swiss company.
I'm sometimes I work as consultant or teacher for some some topics and I I always try to improve my skills and so always a student. I come from Switzerland, from the Italian part, the Italian speaking part of Switzerland and
as I said, I work on a small company called OpenGIS.ch. We are specialized in open source GIS, in QGIS development and Qfield is our product.
Okay, today's presentations, in fact as Tim told before, there are two presentations on more or less the
related topics. I will start with the presentation about strategies, advantages and obstacles in migrations from proprietary softwares to open source softwares. Then
after my presentation Vincent Picave will talk about the alternatives of proprietary software in the open source world and in the end the last presentation is by Marco Beranzocki about
more about economic aspects of migrations. So we try to to split this interesting topic in three parts and to avoid to repeat ourselves in the presentations. So I will start with a very generic and high-level
introduction of this topic. So we will talk about migration, we will talk about converting our architecture to an open source one, but not only or we are not only talking about tools,
we are talking about data, knowledge and everything. First of all, the tools that we have to consider in a migration are
for sure desktop application, the GIS we use on the desktop, mobile GIS, mobile solution, we often in our ecosystem we have mobile solution and
of course a web solution to publish maps on the web. We need a server normally if we want a web solution and a database and for sure other tools. These are all tools we have to consider in a migration.
We will see, as I said after with Vincent, some open source alternatives to these softwares. But not only we have workflows, we have, for example, scripts to import the data, to convert, to analyze
data. We have the knowledge, knowledge in our, in the employees or in the company and that need to be updated to the new solution. We have documentation and everything that has to be immigrated in our, if we want to migrate in an open source
solution. But why? Why should we change our solution? Maybe our working solution that we spend a lot of time and money to build, to convert everything to open source?
What are the advantages? For example, some of the advantages could be the freedom, the freedom from the vendor lock-ins. In fact, we can know exactly what our software does and
we have the possibility to modify it, to change it as we want. We did, we depend on our company. We have the guarantee that our code will always be
available in the future and we will be able to access our data regardless of the will of a company, because everything is open and
we have access to the source code. Also, the speed of improvements, if we want a new feature, if we want a modification in the code, we can always do it ourselves or ask a company to do that.
We don't depend on only on the company that sells the software we use and we have also the possibility to contribute with our modification or our knowledge to the community.
For sure, there are also obstacles in all that. Some of the obstacles are easily solved or there can be more challenging.
But if we know them, it could be easy to prevent them. Some of the obstacles could be the vendor lock-in. Of course, the vendor of a proprietary solution doesn't want to
migrate to other solutions. And they normally don't make everything easy to export all the data or the information in other systems. We have sometimes to
really investigate, to make reverse engineering in the formats, in the files, or how the data is stored. To be able to export everything
Okay, we need to train our staff to the new solutions and be able to
win the resistance to the change. Often there are tools that allow this part of the migration quite easily, but for some parts, we really need to make a deep analysis of the
for example of the format or how the data are stored. And we need a real deep investigation and we have to create some customized tools to do that. But it can be quite easily in our open source
world because there are more and more companies that can work and can create tools to allow exportation of data.
It's not easy to define a solution that works for everyone to to make a migration. It depends a lot on the software that is used, on which part of the existing architecture is to be immigrated.
One possible approach that we use in different solutions is that to have the data, to make the data accessible from the old system and
in parallel from the new open source system, so we can access and work on the same data and then change a step at a time the the other parts.
We will see an example after of one of this part that we we build a tool to convert one of the parts of a complete GIS architecture. Okay, this example concern is related to the symbology.
We had last year a customer that asked us In fact, it's a public administration in Switzerland that they always worked with
ESRI symbology and they had built like 1,200 symbols in ESRI, but they wanted to share the symbols also with users that use QGIS or other
open source software, and they asked us how to export, to convert these 1,000 symbols into something usable into QGIS. These
symbols were composed by points, lines, polygons, and everything, and there was an extensive use of ESRI fonts, and so the requirements were to create the XML library of the symbols that
to be imported into QGIS and don't use proprietary fonts, so remove all the fonts and replace them with something else. The difficulties is
no tools existed to automatically do what we wanted, what we needed. Now there are some proprietary tools that allow to export symbols from ESRI, but
they didn't work perfectly on all our symbols. It was impossible, for example, to avoid the use of ESRI fonts, and the quality of the symbols with images was very bad.
So another problem was the difficulty to interpret the ESRI symbols are all stored in binary files. That looks something like this.
It was very difficult to understand, and in ArcGIS there isn't a way to to create a script to export the information about symbols. It's impossible, unlike in QGIS, it's possible, for example, with a Python script to get all the information of
the symbology you use using a script. So how could we do that? By hand was not a super interesting idea. We didn't want to
draw 1,000 symbols and we wanted to create a tool to do automatically this conversion to be used in the future by everyone. But at first it seemed almost impossible to be able to understand the structure of
of these binary files. But we investigated it a little and we discovered that in the open source world someone already started to build a tool that tried to
to understand the structure of the ESRI style files. This project was created by one of the QGIS developers, Niall Dozon in Australia. And we
we decided to work with him and to contribute to this project with FOUNDS and with COD, and we started to really reverse engineering all the binary files and try to
to convert all the symbols with an automatically tool. And the result is called Slire. It's an open source tool. It's a tool that allowed to convert almost every symbol
from ESRI into a QGIS symbol. It's an open source tool and the main developer is now searching for FOUNDS via crowdfunding to improve new features or to be able, for example, to convert
a mixd project so an ESRI project into a QGIS project. And I will briefly show you a small video
how this tool looks like.
So this is a plug-in for QGIS called Slire. So once the plug-in is installed, there are two algorithms in the toolbox
that can be used. We can select a .style file, so an ESRI symbology library. We can set some parameters like the file where to store the converted symbols.
We can define a folder where to store some pictures and we run this this algorithm in like one minute. All the 1000 symbols are translated. There are some small parts that
maybe some something that exists in ESRI symbol doesn't exist in QGIS symbols, so small parts are not completely converted. On this 1200 symbols, I had to
fix manually like 10, maybe 10 symbols to fix some things. All the rest was perfect. Once our library is created, we can, using the style manager in QGIS,
import our library. We see all the converted symbols. We can select some of them or all of them and import into QGIS.
Okay, so this was a general introduction about the migration topic. This example of
this tool we created, I think it's a good example that shows that something seems maybe very difficult to do, but with good
investigation and analysis, I think it's quite always possible to create a tool to convert everything. The big advantage is that once the work is done, the tool is available for everyone to do the same and make
things easier for the others and maybe make the world a better place. Thank you. Thank you, Mario. We can take some questions from the floor. Gentlemen sitting on the floor.
Okay, all right. So two things. First, I went into the repo and I didn't see a license file, so it will be nice to get a clarification about the license and also about the status of the project because last time I saw
it was almost a year before the code got updated. We're thankful for everything you release, obviously, but we want to see how we can make it progress more. The second thing is we're working on something similar, but for layer X and
the results of ArcGIS Pro, and we'll be happy to cooperate, both open source and commercial level. Thanks for your questions. On the GitHub repository, there is a link on Niall, the developer of this tool, the main developer. There is a link on his website
with more explanation about the status of the project and how to contribute. What we have done, it's all released open source, but I know he's working on more features that maybe are not
released yet. Maybe you can contact him directly. For sure, he has an answer.