Python Bindings für INTERLIS

INTERLIS Werkzeuge
1

Hallo zusammen

Seit einiger Zeit existiert die Idee von Python Bindings für INTERLIS. Dazu haben wir jetzt diesen Blog-Post geschrieben und werden euch in diesem Thread auf dem laufenden halten.

Gerne erhalten wir Anregungen und Kritik :sunglasses:

3 „Gefällt mir“
2

Ein paar Gedanken dazu:

Einfacher und „komplettere“ Informationen ohne Umweg über die DB-Tabellen aus einem Modell zu lesen, verstehe ich und sehe z.B. für Modelbaker einen möglichen Vorteil.

Den QGIS-Drag-n-Drop Usecase sehe ich entweder als Beginn zum Nachbau von ili2db oder nicht sonderlich nützlich. Soll es wirklich mit möglichst vielen Modellen funktionieren, muss man sich doch trotzdem wieder (?) um die Abbildung in den tabellen-orientierten, relationen Raum kümmern, damit ich in QGIS einen Vektorlayer erhalte. Und man muss sich z.B. auch um Abhängigkeiten von Katalogen kümmern, die ich unter Umständen benötige. Jede Option in ili2db hat einen Grund. Wie gehe ich mit grossen Datenmengen? Sind die dann alle im Memory oder werden sie dann trotzdem wieder gecachet (in eine Sqlite-DB? ;)), weil zu gross? Der ili-ogr-Treiber hat m.E. dieses Problem: er liest alles in einen Memorylayer und es wird käsig. Oder es funktioniert nur mit sehr einfachen Modelle oder eingeschränkten Optionen, dann sehe ich aber nicht so einen wirklichen Nutzen. Und ja, eigentlich möchte ich natürlich auch einfach drag n droppen. Aber ein kompliziertes, komplexes Modell ist halt keine Shapedatei.

Modelldokumentation: Man kann bereits heute den Objektkatalog aus einem ILI (resp. aus dem UML?) herstellen. Weil sich niemand darum kümmert, ist der Output visuell bescheiden. Warum man dazu Python benötigen würde, ist mir nicht klar.

Klassengenerator: Wäre wohl natürlicher, wenn man mit Python Python-Klassen herstellt, aber zwingend notwendig ist das wohl nicht. Man müsste bei den verschiedenen Ideen vielleicht auf versuchen aufzuschlüsseln, ob es sich um eine „Runtime-Abhängigkeit“ handelt, oder ob es eine Aufgabe ist, die vor- oder nachgelagert erledigt werden kann. Die Modelldoku erstelle ich auch einmal aus einem Modell und brauch sie nicht wenn ich z.B. mit Modelbaker ein Schema erstelle. Ähnlich bei den Python-Django-Klassen. Siehe auch „Kompromissloser Einsatz von Automatisierung“: Da wird CI/CD erwähnt. Genau hier macht man heute eh einen Mix zwischen jeder möglichen Programmiersprache in einer Pipeline, weil alles gedockert.

Zielgruppe: Was ist für welche Zielgruppe? Die allermeisten Anwender sind keine Entwickler, die würden m.E. höchstens von einem besseren Modelbaker-Support profitieren.

Verbreitung: Hier sehe ich Vorteile, wenn es über den Geo-Tellerrand ausgeht. Hier tummeln sich auch mehr Programmierer, die von der Django-Idee profitieren könnten. Bleibt es im Geoumfeld stecken, droht m.E. ein Fragmentierung. Wie so oft, mangelt es in der Schweiz nicht am Geld, sondern am aktiv Mitwirken. All das muss wieder supportet sein, all das muss wieder dokumentiert werden etc. pp.

All jene, die Python-Bindings wollen, sollen sie nicht nur finanzieren helfen, sondern sie sollen explizit darlegen, wo sie ein Bedürfnis haben und sich committen mitzuarbeiten. Auch wenn es wieder in einer nächsten Arbeitsgruppe / einem nächsten Verein endet, wo man einen Obulus abdrückt und/oder einen Ablasshandel macht und gut schläft.

3

Hi all,

Here below are some thoughts about this proposal.

There are several possible benefits to setting up a python binding:

  • Broadening the community willing to invest time and money in the development, documentation and coordination of projects linked to Interlis. Indeed, the python language seems (to be confirmed by real data…) to be the most widespread among new generations of geoinformation workers;
  • Greater accessibility to the development of tools around Interlis in the QGIS context could result in easier and faster onboarding of new Interlis users. Indeed, we could expect a new ecosystem of plugins around Interlis to become available for QGIS. Reducing the small initial difficulties in using the tools around Interlis should not have any negative consequences. The impact of ease of onbarding on the adoption of a solution by a community should not be underestimated. The question of performance on large datasets should be assessed beforehand.
  • Simplify the integration of interlis in ETLs other than SAFE FME, and in particular the possible Open Source ETLs;
  • Control models derived from interlis using an ORM would provide significant added value in terms of managing spatial data infrastructures, while it’s true that this approach is still quite uncommon in the geospatial world. In the longer term, we could imagine being able to deploy OGC APIF services in a particularly simple and effective way using an Interlis model, enabling a large number of users distributed across several organisations to contribute more fluidly to updating geodata.Let’s dream :wink:
3 „Gefällt mir“
4

Broadening the community willing to invest time and money in the development, documentation and coordination of projects linked to Interlis. Indeed, the python language seems (to be confirmed by real data…) to be the most widespread among new generations of geoinformation workers;

Money never was an issue (can change of course). And what prevents users from creating great user manuals and cookbooks etc? I don’t think it’s the underlying technology of the tools.

Indeed, we could expect a new ecosystem of plugins around Interlis to become available for QGIS.

What is missing?

Simplify the integration of interlis in ETLs other than SAFE FME, and in particular the possible Open Source ETLs;

Out of interest: Are there any good open source etl tools out there? And I still wonder why anybody wants to use FME for dealing with INTERLIS. It seems to complicate things. But this is probably just me.

Control models derived from interlis using an ORM

If you go with a database first approach you can already start with an INTERLIS model and let the ecosystem create the classes / entities. But yes, you will probably loose some information (like now in Modelbaker). But I honestly don’t know if these losses really hurt in the end.
Concerning OGC APIF: Does it get any simpler than creating the tables with e.g. ili2pg and then using an existing ogc api feature software?

5

My guess would be that as most people around QGIS are quite fluent in python, python bidings could help. But you are probably right.

1 „Gefällt mir“
6

I guess that as most GDI rely on FME, keeping all data processes inside the same environnent is appreciated. There are some Open Source ETLs that are interesting (Talend for instance) but they are very, very far from FME when it comes to spatial data.

7

In a sens it’s not directly related to interlis. And yes, you are right we can live with the existing tools. Still using ORM tool to control DB models using code brings stability. But this is probably out of scope.

8

I guess that as most GDI rely on FME, keeping all data processes inside the same environnent is appreciated. There are some Open Source ETLs that are interesting (Talend for instance) but they are very, very far from FME when it comes to spatial data.

Which is written in Java (if I remember correctly). There is/was Kettle and now a fork called Apache Hop https://hop.apache.org/ which is also written in Java.