Using KML to import styles from Geomedia and ArcGis
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Anzahl der Teile | 37 | |
| Autor | ||
| Lizenz | CC-Namensnennung - Weitergabe unter gleichen Bedingungen 3.0 Deutschland: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen und das Werk bzw. diesen Inhalt auch in veränderter Form nur unter den Bedingungen dieser Lizenz weitergeben. | |
| Identifikatoren | 10.5446/40798 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Schlagwörter |
3
5
8
13
17
19
26
00:00
SoftwareentwicklerFeuchteleitungCodeSystemplattformVersionsverwaltungWeg <Topologie>DatenverwaltungProgrammfehlerMigration <Informatik>TemplateBenutzerfreundlichkeitKonfigurationsraumCoxeter-GruppeGüte der AnpassungMultiplikationsoperatorRegulator <Mathematik>GrundraumQuellcodeLeistung <Physik>DialektRechter WinkelInformationsspeicherungKontextbezogenes SystemRechenwerkt-TestMathematikGraphfärbungBildschirmmaskeGeradeSoftwaretestSystemplattformVarianzPhysikalische TheorieKlasse <Mathematik>Metropolitan area networkSoftwareGruppenoperationInternet der DingeRandwertTopologieCASE <Informatik>Mathematische LogikART-NetzDatenverwaltungProjektive EbeneFrequenzGradientVerkehrsinformationInnerer AutomorphismusMereologieVersionsverwaltungStützpunkt <Mathematik>Spezielle unitäre GruppeBitSchlussregelOpen SourceKonfigurationsraumWikiData MiningTermQuantengravitationCodeDokumentenserverKontinuierliche IntegrationAbgeschlossene MengeProzess <Informatik>Elektronische PublikationPlastikkarteKartesische KoordinatenFeuchteleitungAttributierte GrammatikXMLComputeranimation
07:34
EindringerkennungLokales MinimumMenütechnikGammafunktionZeiger <Informatik>Konvexe HülleAbelsche KategorieTextur-MappingIdentitätsverwaltungVerschlingungDateiformatSpezialrechnerQuantisierung <Physik>SpeicherabzugInverser LimesSoftwareentwicklerRückkopplungSoftwareentwicklerÄhnlichkeitsgeometrieApp <Programm>Inverser LimesAuszeichnungsspracheMessage-PassingTermProzess <Informatik>RoboterData MiningMultiplikationsoperatorSystemaufrufAttributierte GrammatikElektronische PublikationMultifunktionAutorisierungProjektive EbeneMAPRechter WinkelDatenverwaltungDokumentenserverSchlüsselverwaltungSkriptspracheMigration <Informatik>Inhalt <Mathematik>VerschlingungRechenschieberDateiformatMapping <Computergraphik>EindringerkennungFahne <Mathematik>Bildgebendes VerfahrenAggregatzustandSichtenkonzeptWeb SiteMetropolitan area networkArithmetisches MittelTelekommunikationExogene VariableRegulator <Mathematik>BildverstehenVollständiger VerbandPartikelsystemPhysikalische TheorieRelativitätstheorieResultanteVektorraumVarianzURLImplementierungAdhäsionInvarianteComputeranimation
15:02
PunktwolkeVektorraumResultanteSoftwarepiraterieZahlenbereichProzess <Informatik>MultiplikationsoperatorWald <Graphentheorie>Physikalische TheorieStandardabweichungStabVersionsverwaltungGüte der AnpassungLASER <Mikrocomputer>Automatische HandlungsplanungEinfügungsdämpfungLesezeichen <Internet>Strategisches SpielRelativitätstheorieMathematikDatenflussRechter WinkelRouterSchnittmengeDivergente ReiheIntegralHypermediaLaurent-ReiheSoftwareentwicklerProjektive EbeneQuellcodeInverser LimesSicherungskopieMereologieAggregatzustandOpen SourceRückkopplungSystemplattformQuantengravitationExogene VariableBitKontinuierliche IntegrationSkriptspracheVollständiger VerbandXMLComputeranimation
22:31
EDV-BeratungElementargeometrieComputeranimationJSONXMLUML
Transkript: Englisch(automatisch erzeugt)
00:05
Good morning everybody. I'm very glad to be here to do this presentation. My name is George Ustafu. I teach at the University of Mignon, but I also started a company called Geomaster.
00:25
And I'm Paul Oleda. I'm a colleague on Geomaster. Hello George. So, we are here to discuss this topic. For sure, most of you already submitted issues to Kijis.
00:46
And our motivation, although this will be a technical presentation about the technical part of doing this work, but the major motivation of this work is related to openness.
01:01
We are always talking about open source and everything related to open, but things to be open must be easy, must be transparent and so on. And right now our red mine requires a new account, has a textile formatting style, an old fashioned one and so on.
01:26
When we do presentations about Kijis, we'd like to point to our repository on GitHub, but people will not find the issues there and we have to explain. But the issues are around another place and so on, so I think making the
01:42
code in the same platform as the issues are a much more clear and transparent way. And also, lowers the barrier for new users, so it will be easier for new users to report bugs, to request new features and so on.
02:04
And maybe we'll create many new issues on our queue, but we are also able to have more people dealing with these issues, which is also important. It's quite difficult to do the triage, privatization of features and so on, and right now it's done only by two or three people.
02:27
So with this approach we'll have more people able to manage the issues. Really the technical part. So having the code and the issues on the same platform, we can close pull requests or we can close issues in pull requests.
02:48
We also have nice features from, in this case, GitHub. We have project management, we can create cards, even we can use automated ways to move through issues.
03:01
We can use Android and put on the card and can create different columns, we can show it later. And also, GitHub has much more powerful API and more applications able to work with the API. Also, in terms of costs, it will be one less platform for the QG's to manage and to keep up and running.
03:25
And also, red mining is becoming quite old, as all of us. It's version 2.5 and right now it's already on version 4 and it's quite complicated to upgrade red mine.
03:42
So, this is the most important part, the motivation, and now comes our goal. Our goal is to move away from red mine. It's a recurring topic in our community. We are always talking about this. We tried last year a different approach, trying to move everything to GitHub instead of GitHub.
04:07
We tried to go to an open source platform as GitHub and change to GitHub the code issues, the wiki and the continuous integration. But we found out that there will be too much changes for us.
04:24
So, this time we are trying to, just in one step, just one thing, try to move issues from red mine to GitHub. So, in this presentation we will show some tests that we have made and the challenges.
04:44
The challenge is to preserve the history. It's very important to preserve this, but it's clear since the beginning we are not killing the red mine. The red mine can be up and running and can become read-only and if it will become
05:00
read-only it will be easier to keep and to maintain, just to protect everything as it is. But also the challenge is to keep the history and to keep the owners of the issues, the comments and so on, and keep references between issues. Let's say how we have done this.
05:23
So, we could do this in several ways. One first approach is to migrate everything that we have in red mine and put it in GitHub. Another approach is just to transfer issues related with our current 3.x versions.
05:46
And since the version 2 is not being out there anymore, so LTR, so we can just keep this platform on GitHub with the issues from version 3 and up.
06:03
We can only create open issues and use all the closed issues that will remain on red mine. Or even we can do a clean start and write down new issues on the GitHub and keep all the issues on red mine and this will be the easiest way to do this migration.
06:30
So, maybe all the code, so we might switch. So, if we don't do the clean start we have to actually get the issues and put them on GitHub.
06:45
We did this with taking advantage of the REST API, both on the red mine and the GitHub side. We separated the process in two steps. First we get all the issues from red mine, all the desired issues.
07:00
You can filter by status, open or closed. Then we collect these issues on JSON files that have all the things related to them, the attachments, the common history, etc. And along with some manual configuration where we will say what red mine attributes translate to GitHub
07:26
labels and where we will map the users, the red mine users to GitHub users if we want. We migrate this to the GitHub repository as issues and we also create an issue
07:43
map that preserves this relation, the IP on red mine and the IP on GitHub. If you want to, because we will need this in a further step to keep the references in the issues. When issues come, past issues on the red mine side, we use the IP that red
08:06
mine has and in our new migration we have to know that to correct that reference. We did this on a GitHub repository that we created with a user key issue bot.
08:23
Here we have some results. On the left side we have a red mine issue. On the right, the corresponding GitHub and how we coded out the contents that are corresponding.
08:41
The author is preserved, the dates, the flags in red mine are converted to labels in GitHub. Next slide we will see that it's similar for the comments.
09:01
We can also see that now that we are on GitHub, preferences to the comments are automatically linked by the GitHub API. These IDs of the comments are preserved and easy to navigate. In GitHub we can take advantage of both the GitHub's project management tools and also a collection of apps that use the GitHub API.
09:30
Here we have an issue prioritization tool. In GitHub we could have also a KanBank for project management.
09:40
It's an example of what we can take advantage of if we migrate. I don't know if you can read, but we can create different columns and right now in this column will be issues needing triage, high PRD issues, low PRD issues and so on. We can automate this and it can be easier for people managing issues to follow these columns and move things around columns and so on.
10:11
You can automate this process. In terms of limitation of this approach, as we already said, both the correspondence of
10:23
the attributes in the red mine side, the linking between authors in red mine and GitHub, and it has to be manual configured if we want to keep those references of the plain authors.
10:41
The references to other issues on the red mine side and on the GitHub side require the second pass of our scripts because on the first pass, the GitHub will wrongly assume that an issue 11, that was issue 11 on red mine, will be the issue 11 on GitHub.
11:03
We won't have that assurance, so we need a second pass of our script with the marking file that we mentioned to correct these references. And also the text format on red mine is on text file. Our scripts are not resolved for now. The markdown that is expected on the GitHub side is also limitation for now.
11:27
Here we have some images that display these limitations. On the left side, we have authors up. There is an author that was on the mapping file. So, if we feed the script with the mapping of users on our red mine and the users on GitHub,
11:52
it will resolve the names and the new issues will have the name and automatically the link to the user. For users that we don't have the GitHub account, we'll just display the names.
12:08
On the right side, we have an issue that was referenced on the comments that is wrongly assumed to be issue 11 on GitHub, but it's a wrong assumption. It was issue 11 on red mine and it has to be corrected on the second pass.
12:23
Here we see this kind of show here in Google that this corresponding of attributes of red mining to GitHub labels has to be discussed and our work. Right now we are putting everything as a GitHub label with no formatting of the kind of color, if you want.
12:46
So right now it's really bare bones, so it needs more work and discussion. And here in green, the new limitation. It's the textile markup that is not being corrected to markdown.
13:10
So, I have two minutes for conclusions. So, Paul was working on this and other developers here I know that already have been working on this.
13:23
This is a recurring topic, but this last exercise that we did, we successfully were able to transfer issues, comments, attachments and so on within the files and everything related to the original issue is migrated to GitHub.
13:47
The limitation is that this new account or the account that we create for this migration, the issues will start with the owner, with some QGIS issue bot or something.
14:03
On the technical side, Paul has some troubles with the amount of calls of the API. Maybe we have to talk with them to allow us during two days to call a lot of times the GitHub API or do it more slowly.
14:24
And I think that we didn't explore the second pass, but we have everything set up for the second pass. And the most important thing, and that's why we are starting this discussion right now, is to gather the developers in the act-fest and discuss which labels we need to have on GitHub to properly configure the issues.
14:51
So this is the main question here, which labels we need on GitHub. And I think we covered all the aspects, but for this, which users will open a QGIS announcement proposal and write down our first proposal.
15:18
Thank you for being here and let's discuss this.
15:35
Oslandia also did something like this. Did you discuss this yet then?
15:41
Oslandia have made the exercise to migrate to GitLab instead of GitHub. So I think since we improved the continuous integration in GitHub, people are more satisfied with the current status, so we don't need to move everything from GitHub.
16:00
But it's not very different. The thing, our proposal right now is just do one step and move the issues to GitHub. In some day in the future, if you decide to move to a more open source platform like in GitLab, it will be easier because everything is Git-based and so on.
16:21
So I think it will be easier to migrate from GitHub to GitLab if we do this. I think the most complicated part is moving issues from Redmine to GitHub. Did you already try to contact GitLab crew to understand if there is some possibility to an Hadoop
16:47
integration or at least turn off the limitation of number of API calls to be more quick in development? Not yet.
17:00
Because our response is normally when you write them, so maybe for a small project like that can help us. Yes, I think it will not be a problem if you explain to them what we want to do. I asked them and they said no, but it's actually 5k per hour and not per day, so
17:24
if we have 20,000 tickets it should take 4 hours. I think we're doing 17,000 times. Yes, but we are not able to do so many. There is some problem, we are trying and the script ends much sooner.
17:41
Ok, but let's say even if we do 20 hours, I think it's not going to be an issue. Yes, I agree with you. But right now the limit is lower than the limit. From a standard point of view, we've reached almost the same state to GitLab, so it's very similar.
18:01
The main question to me is more about the fact that GitHub is centralized and GitLab, we could host it ourselves. And what I'm afraid of for the project is that the main value we have is the source code because everyone has it on Git repos everywhere. But the issues, they would be locked in GitHub, so that's the main strategic question.
18:25
Do we trust in or do we keep mirrors somewhere else and migraines regularly and backup issues so that we can switch to GitLab if one day Microsoft changes its policy? I think the main strategic question is there.
18:42
My suggestion is to keep a mirror of this and try to start the exercise with GitLab. I do prefer GitLab. So I would start the exercise trying to have a mirror on GitLab and so on and even improving the continuous integration, the deployment and so on.
19:01
I think we should improve our workflow, even the workflow related to the producing package for all platforms and so on. So I think we have more freedom on the GitLab side, but as we know, it's so difficult to move things and to convince people that we need to change and so on.
19:22
So let's do it in small steps instead of a larger step. I agree with you, it would be very nice, but we'll keep it in smaller steps. Yeah, but it would be in fact to use GitLab as a backup for us to be independent.
19:42
I agree. Denis? We're very happy to see that today. I don't think there are any technical problems under the issue here and I'd like to know if you have any plans to contribute or learn the roadmap for applying this. Do you have any idea?
20:02
Our plan was to open this Fugees and Anselm proposal to discuss which labels we should use in GitLab, but that's I think the only thing that we need to agree, all of us. But I think it will be easier for us that we are already here, but maybe for all the developers that are not here,
20:25
just to close this proposal related to which labels to use and afterwards I think we can migrate in 20 hours or something like that. Just like the decision, how do we take it?
20:43
I think we have something called PSC. PSC says write a plan or do a plan or do it. Nobody does. You propose something. Yes, yes, but we are here and Paul came here to work this every day for the, so we are willing to do this.
21:10
Last question. Just two things. On one hand we already have documentation issues on GitLab, so anyway it makes sense.
21:21
I'm absolutely for you, so the only problem with what Denny just said is we cannot just say here it is, we do it. There's been so many discussions, we just need to kind of politically decide that and then it's super cool that you did all the work already.
21:41
We need to have a plan, say okay now we will do this. So the first thing would be we have a QFP, we do it, then it would be like this when people would say yes or no and not but and if or whatever, yes or no. And then we implement or we don't implement. We need to reach a consensus.
22:03
There was actually a meeting planned for tomorrow, discussing exactly about that. It was a bit of a surprise to see this, but a super good surprise for me. Thank you. And thank you very much for your feedback. I will write down the QG's announcement proposal with a very detailed plan to discuss it further and to present to the PSC.
22:25
Thank you all. Thank you.