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

Malinki - Erstellung kartenbasierter Mobile Apps ohne Programmierung

00:00

Formal Metadata

Title
Malinki - Erstellung kartenbasierter Mobile Apps ohne Programmierung
Title of Series
Number of Parts
88
Author
License
CC Attribution 4.0 International:
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
Malinki ist eine quelloffene und konfigurierbare native mobile App, mit der raumbezogene Informationen ohne Programmieraufwand in speziell für Smartphones optimierten interaktiven Karten veröffentlicht werden können. Neben der Präsentation der Merkmale und der Architektur wird die Konfiguration und Nutzung der App demonstriert.
Keywords
Computer programmingComputer fileApple <Marke>Block (periodic table)Portable communications deviceMobile appSoftwareprojektSmartphoneConfiguration spaceMemory cardSmart cardiPhoneGreatest elementVariable (mathematics)Computer programmingMAPPERGeodesicSpatial data infrastructureSphereWeb browserSource codeObject-oriented programmingService (economics)Graphics tabletLevel (video gaming)Aktion <Informatik>Focus (optics)Link (knot theory)LaptopMeeting/InterviewXML
Object-oriented programmingSource codeWEBCodeMetreWorld Wide WebiPhoneView (database)Mobile appServer (computing)Memory cardHighlight <Programm>Query languageBildpyramideConfiguration spaceVector graphicsData typeGebiet <Mathematik>Source codeVariable (mathematics)VECTOR <Programm>GeometryAsset <Informatik>Object-oriented programmingSpatial data infrastructureService (economics)Function (mathematics)Smart cardGeometryProgram flowchart
Maximum (disambiguation)Game theoryCAPE <Informatik>ACIDWEBSource codeTransmitterVECTOR <Programm>Variable (mathematics)Set (mathematics)NumberTransformation (function)Apache <Programm>Uniform resource locatorObject-oriented programmingVersion <Informatik>Mobile appLaufzeitConfiguration spaceService (economics)Link (knot theory)WhiteboardGebiet <Mathematik>CASAsset <Informatik>Computer animation
Android <Systemplattform>Online chatDirection (geometry)Link (knot theory)Version <Informatik>Open sourceMobile appLimitierungsverfahrenMeeting/Interview
CompilerMobile appMeeting/Interview
Meeting/Interview
Mobile appMeeting/Interview
LimitierungsverfahrenMobile appMeeting/Interview
Meeting/Interview
MARKUS <Unternehmensspiel>
Transcript: German(auto-generated)
Ja, wir beginnen mit dem dritten Vortrag in diesem ersten Block. Es geht wieder um Karten, aber diesmal auf Mobilgeräten. Christoph Jung ist hier und wir zeigen einen Vortrag Malinki, Erstellung kartenbasierter Mobile Apps ohne Programmierung.
Hallo und herzlich willkommen zu Foskis 2022. Mein Name ist Christoph Jung und in den nächsten 20 Minuten möchte ich Ihnen mein Softwareprojekt Malinki vorstellen und Ihnen zeigen, wie man mit Malinki ohne zu programmieren eine kartenbasierte Mobile App erstellen kann. Eigentlich wollte ich einen fertigen Stand der Entwicklung präsentieren,
also bei so einem 1.0, aber wie das bei Freizeitprojekten ist, es gibt Tage, da kommt man richtig gut voran und es gibt Wochen, da kommt man zu gar nichts. Insofern ist das jetzt erst mal nur ein Zwischenstand, aber einer, bei dem wir schon sehr viel sehen können. Ich denke, das lohnt sich schon, hier mal reinzuschauen. Malinki selber ist eine konfigurierbare, native Mobile App um raumbezogene Daten,
vornehmlich über OGC-Services, speziell für Smartphones optimierten interaktiven Karten darzustellen. Und wir sehen hier rechts auch schon einen Screenshot direkt aus einer App, die ich mit Malinki erstellt habe und die einfach ein paar Beispieldaten beinhaltet. Aber was bedeutet das jetzt ganz genau? Wir haben im GIS-Bereich eigentlich einen Dualismus
und zwar aus GIS-Applikation und aus Geodaten. Beides sind sehr komplexe Objekte, die Daten an sich, aber auch die Applikation und nur zusammen bringen die uns eigentlich was. Wenn ich einen Kugels einfach so starte, ohne Daten drin, dann sehe ich nichts. Ich brauche also zwingend die Daten, die Daten selber bringen mir oftmals ohne einen Kartenbüro
und auch nichts. Malinki selber ist jetzt eine Applikation. Die ist fertig lauffähig, die App. Man kann sie also einfach starten, aber man sieht nichts drin, denn es fehlen die Geodaten. Diese müssen noch extra hineinkonfiguriert werden und sind natürlich immer abhängig davon, was für eine App ich erstellen möchte. Für das Ganze könnte man natürlich auch ein WebGIS nehmen,
denn ein WebGIS läuft im Browser und ist damit lauffähig auf einem Desktop-PC, auf einem Tablet und auf einem Smartphone. Aber es gibt Gründe, warum man eine Mobile App dafür nehmen sollte. Das eine ist die Größe und die Form des Displays, die sehr unterschiedlich sind. Und damit ist ein WebGIS, das auf einem Desktop-PC genutzt wird,
nicht zwingend gut nutzbar auf einem Smartphone, teilweise auch gar nicht nutzbar. Die Eingabemöglichkeiten sind unterschiedlicher. Maus gegenüber Touch-Bedienung. Aber auch die Nutzungsgewohnheiten sind sehr unterschiedlich, je nachdem, wo die Nutzenden unterwegs sind. Wer mehr dazu wissen möchte, ich habe auf der letzten FOSGIS auch einen Vortrag darüber gehalten,
warum man das Smartphone mehr in den Fokus in der GIS-Branche rücken sollte oder auch hier im OpenGIS-Bereich. Hier auch nochmal der Link dazu. Mit Malinki versuche ich da gewisse Sachen besser zu machen. Das Wichtigste ist eigentlich eine auf Smartphones optimierte Kartenpräsentation. Das ist das Wichtigste. Das bedeutet, dass die Karte das wichtigste Objekt ist in meiner App.
Und alle anderen Bedienelemente auf ein notwendiges Minimum reduziert werden. Zum Beispiel Plus-Minus-Buttons brauche ich auf einem Smartphone nicht, denn das mache ich mit Pinch-in-Pinch-out mit den Fingern. Die Daten selber werden über OGC-Services konsumiert. Das heißt, die App selber passt sich perfekt in eine bestehende Geodateninfrastruktur an,
ohne ein bestimmtes System vorauszusetzen, weil ich einfach bestehende Dienste nutze. Die Konfiguration und Administration der App ist sehr einfach, wird über eine zentrale Konfiguration geregelt und die ist im JSON-Format gehalten. Das bedeutet, ich muss also nichts entwickeln. Ich muss eine Quellcode übernehmen, um meine Daten zu integrieren
und erleichtere damit natürlich den IT-Betrieb. Und zukünftig soll es auch möglich sein, das ist natürlich als um 1.0 geplant noch, Push-Mitteilungen zu veröffentlichen über die App. Das heißt, User haben dann die Möglichkeit, über die gleichen Applikationen, über die sie schon die Daten konsumieren, eben auch über Karten oder Änderungen
in den Geodaten informiert zu werden. Das war jetzt ein bisschen viel Theoretisches. Wir schauen uns das Ganze jetzt einfach mal im System an. Zu Präsentationszwecken habe ich hier Dienste des Deutschen Wetterdienstes eingebunden. Und das Ganze läuft jetzt hier auf einem iPhone 7,
das ich an meinen Laptop angebunden habe. Das iPhone 7 ist nicht gerade der aktuelle Hardware, zeigt aber wunderbar, dass das Ganze doch ziemlich performant läuft. Wenn wir die App gestartet haben, sehen wir, dass lediglich zwei Bedienelemente die Karte überlagern. Ansonsten ist der gesamte Bildschirm mit unserer Kartendarstellung versehen.
Der obere Button bietet die Möglichkeit, das Kartenthema zu wählen oder die Grundkarte zu ändern. Der untere Button ist dafür da das aktuell gewählte Kartenthema, also sprich, die Karte, die ich jetzt sehe, inhaltlich zu steuern, also sprich, ob ich bestimmte Mapper sichtbar haben möchte oder nicht.
Ich kann hier mit zwei Fingern einfach rein rauszoomen und dann den Maßstab verändern. Wenn ich das mache, wird links oben auch eine temporäre Maßstabsleiste angezeigt. Und ich kann auch mit zwei Fingern ganz normal den Karteninhalt drehen, dann wird rechts oben auch ein Kompass angezeigt. Aber das Ganze verschwindet dann auch wieder, das ist also nur temporärer, solange ich die Aktion ausführe.
Die Daten, die wir hier sehen, sind serverseitig gerenderte Daten, also WMS, WMTS. TMS wird als Datenquelle unterstützt. Die Grundkarte ist OpenStreetMapped, diese WMTS, die Relief-Darstellung ist ein WMTS. Und zum Beispiel die Ländergrenzen sind WMS-Daten.
Schauen wir uns mal die Map Player an. Genauso wie man das im GISS kennt, ist das hier auch entsprechend sortiert, dass wir ganz oben die Daten haben, die auch in der Karte ganz oben gerendert werden. Also hier zum Beispiel die Städte und ganz unten dann die Relief-Darstellung. Und einfach, wenn ich diesen Schalter rechts betätige,
werden die Daten ein- oder ausgeblendet. Habe ich alles ausgeblendet, bleibt natürlich nur die Grundkarte übrig. Bei der Grundkarte habe ich die Möglichkeit, selber Daten vorzugeben. Ich habe jetzt hier OpenStreetMapped eingebunden, aber weil es eine 100% native App ist, bietet es mir auch die Möglichkeit, zum Beispiel Apples Kartendienste einzubinden.
Hier zum Beispiel die physischen Daten, Luftbild oder eine hybride Darstellung. Ich kann dann wie gesagt auch die Daten wieder zuschalten. Und wie man hier beim Relief sehr gut sieht, das Relief scheint so ein bisschen durch. Ich kann in der Konfiguration auch angeben,
wie durchscheinend ein Layer dargestellt werden soll. Wechseln wir mal das Kartenthema zum Thema Wetter. Da sehen wir nämlich, dass weitere Elemente auf der Karte hinzukommen, nämlich sogenannte Annotations. Das sind einfach zusätzliche Anmerkungen, die oben auf die Karte nochmal draufgesetzt werden.
Und über diese wird die Interaktion mit dem Karteninhalt generiert. Also ich kann jetzt nicht irgendwo in die Karte hineinklicken oder tippen, lange gedrückt halten und dann Sachdaten abfangen, sondern das geht nur mit diesen Annotations. Das muss vom App-Anbieter vorher eingestellt werden, wo diese Positionen sind
und wo ich zusätzliche Daten abfragen kann. Dafür gibt es dann bei den Layern auch einen zusätzlichen Eintrag. Ich habe das jetzt einfach hier Marker to Query Data genannt. Das kann ich ausmachen und dann sind diese Annotations dann auch wieder weg.
Annotations muss es nicht zu jedem Kartenlayer geben. Ich muss in der Konfiguration angeben, zu welchem Layer ich Annotations und damit auch Sachdaten abfragen erlaube. Machen wir einfach mal alle Karteninhalte aus, alle Layern und schalten die Annotations wieder dazu.
Da ich keine Kartenlayer habe, werden jetzt natürlich auch keine Annotations angezeigt. Ich nehme jetzt mal den Temperaturlayer hinzu und dann sehen wir, dass zum einen Temperaturen gerendet werden und zum anderen auch unsere Annotations vorhanden sind. Die Annotations werden automatisch gruppiert, wenn es zu viele auf einem Schlag sind. Ich kann sie hier auch reinzoomen und kann es einfach mal eine Abfrage machen, indem ich einfach eine Annotation selektiere
und dann wird in dem Fall ein Get Feature Info Request abgesetzt am Server und die Antwort wird dann hier dargestellt. Ich habe jetzt hier als Datenquelle die Temperaturen. Das ist eine reine Rasterdatenquelle.
Wenn ich jetzt einfach mal die Warnungen auf See aktiviere, dann habe ich da im Hintergrund aber eine Vektordatenquelle und das ist etwas ganz Interessantes. Wenn ich jetzt hier zum Beispiel mal das Skagerag auswähle,
werden eben beim Get Feature Info Request nicht nur die Sachdaten abgefragt, sondern auch noch die Geometrie, sodass ich das Objekt, das ich selektiert habe, auch noch Highlighten kann. Und die Sachdaten sind dann hier in einer Liste so dargestellt, wie es der Server zurückgibt.
So, wir haben das Ganze jetzt einfach mal im System gesehen und dazu noch ein paar Vormerkungen. Wir haben gesehen, das Ganze sieht wie eine native iOS App aus, denn es ist eine 100% native App und das ist der Nicht-Foss-Teil, das heißt, das Ganze ist in Swift geschrieben und die Karten-Darstellung erfolgt über das Mapkit-Framework. Ich habe das nur an einzelnen Stellen erweitert bzw. Funktionen überschrieben, um OGC-Services einbauen zu können.
Bevor wir uns einfach mal anschauen, wie wir so eine App konfigurieren, möchte ich einfach noch mal ein kleines Schaubild zeigen, wie die Architektur der Geodateninfrastruktur ausschaut. Das erleichtert dann doch, glaube ich, das Verständnis, was ich dann mache. Im Zentrum steht natürlich unsere App mit der Karten-Darstellung und die wichtigsten Kartenobjekte für die App sind einmal Grundkarten und Layer, die noch zu Themen zusammengruppiert werden.
Es handelt sich hierbei in beiden Fällen um entweder serverseitig generierte Daten oder vorgerenderte Daten, also WMTS und TMS stehen hier als Datenquellen zur Verfügung.
Diese Karten werden dann auch lokal auf den Clients, also auf den Smartphones, gecached. Das hat nun mal den Vorteil, ich muss mal einmal so ein Request am WMS absetzen, im GetMapRequest, um die Bildkarre zu erhalten. Und wenn ich wieder in das Gebiet komme, im gleichen Maßstab, ziehe ich die einfach direkt aus dem Rahmen raus.
Es gibt auch noch zwei andere Kartenobjekte, das sind Annotations und Vector Shapes genannt, also Vector Geometrien zum Highlighten von Objekten in der Karte. Diese benutze ich für die Objektabfrage, für nichts weiter. Und weil es sich hier um Vektordaten handelt, muss ich natürlich auch Vektordatenquellen unterstützen,
und das sind in dem Fall BFS und GeoJSON. Bei den Vector Shapes, also zum Highlighten von Objekten, wenn ich eine Sachdatenabfrage getätigt habe, besteht auch die Möglichkeit, das über ein WMS zu machen. Denn wenn der Service den MIME-Type Application JSON unterstützt, beim Info-Format, dann kann ich darüber ja genauso auch eine Geometrie miterhalten.
GeoJSON und auch Bildpyramiden können auch lokal auf dem Gerät nicht liegen, also in die App integriert werden, sodass ich hier eine gewisse Offline-Fähigkeit habe. Ja, das war jetzt erstmal das Schaubild, wir gucken uns jetzt einfach mal an, wie das System ausschaut. Die App zu erstellen und zu kompilieren gibt es ein Xcode-Projekt.
In dem können wir die gesamten Quellcode eigentlich ignorieren und uns lediglich auf die Konfiguration und auf die Assets konzentrieren. Assets sind dann einfach Bilder, Farben, die man definiert und hier einbindet. Schauen wir uns erstmal die Konfiguration an. Diese besteht aus insgesamt drei Einträgen,
nämlich den Kartenthemen, den Basemaps und eine Einstellung, was beim Appstart passieren soll, nämlich welches Kartenthema und welche Basemap angezeigt werden sollen. In beiden Fällen machen wir einfach mal hier eine Null, also das Ganze wird über eine ID referenziert.
Wir haben hier einfach mal eine leere Konfiguration, wo ich einfach nur ein paar Platzhalter drin habe und wir schauen mal, wie das Ganze ausschaut, wenn wir jetzt die App starten. Wir haben hier einen Simulator dafür und wir sehen, es ist keine Karte sichtbar. Wir können hier die Buttons benutzen, wir haben hier einen Platzhalter für ein Kartenthema,
wir können die Basemaps auch aufrufen, da ist nichts zu sehen drin. Karteninhalt sehen wir auch, dass wir hier einfach nur Platzhalter haben, mehr nicht. Wir haben also keine Daten drin. Die App an sich ist lauffähig, aber unsere Daten fehlen und die fügen wir jetzt hinzu. Damit fangen wir erstmal bei den Grundkarten an.
Der Aufbau ist relativ simpel. Wir müssen hier eine ID mitgeben, fangen wir einfach mal bei Null an. Ein internen Namen, das nenne ich jetzt einfach mal osm, weil wir die OpenStreetMap-Daten einbinden wollen. Wir vergeben noch einen externen Namen und haben dann die Auswahl,
um was für ein Datentyp es sich handelt. Die Grundkarte ist erstmal Rasterdaten und damit können wir mit TMS, WMS, WMTS arbeiten oder Apple-Karten anbieten. Die OpenStreetMap-Daten liegen als TMS vor. In der URL selber müssen Platzhalter drin sein für Z, X und Y, damit der Aufruf für den TMS
entsprechend erstellt werden kann. Wir können auch angeben, ob die Y-Achse invertiert ist oder nicht. In dem Fall ist es nicht. Wir würden einfach noch eine zweite Grundkarte erstellen. Die kann ich einfach über das iPhone-Auflistung,
also ein Array ist, ein Komma und dann das Ganze hineinkopieren wieder. Wir geben eine neue ID, die eins jetzt einfach mal hochgezählt und nennen das Ganze jetzt AppleRoads. Das Ganze ist dann vom Datentyp kein TMS mehr. Deswegen ersetzen wir hier die Konfiguration von Eben mit dem Wert Null. WMS und WMTS ist es auch nicht,
sondern es sind Apple-Karten. Das machen wir also in True rein. Und das war's für jetzt. Starten wir die App und werden sehen, dass da auch schon eine Grundkarte drin ist. Einmal OpenStreetMap, weil wir das als Start-Grundkarte gewählt haben. Und wenn wir jetzt hier ganz schön was noch gibt, sehen wir auch,
wir können hier uns auch noch Apple-Karten anzeigen lassen. Aber in diesem Dialog hier unten, überfällt uns auch irgendwie eine grafische Repräsentation. Hier kann man nämlich ein Bild hinterlegen, um dem Nutzer dann die Auswahl zu erleichtern. Das ist dann das sogenannte Image-Name.
Um die Bilder mitzugeben, muss ich jetzt in die Assets reingehen. Und hier gibt es ein Ordner Basemap-Images, wo man das reinlegen kann. Ich habe das schon mal vorbereitet. Zwei Bild-Dateien sind eigentlich nur PNGs, die bei Drag&Drop hier rein. Man muss dann einfach diesen Namen hier einbinden. Ich abbiege mir das schon mal. Dann füge ich das hier ein.
Einmal für die Apple-Karten und den OSM-Basemap. Jetzt starten wir das Ganze wieder. Und dann wird die App anhand des Eintrags in der Konfiguration und in den Bild-Dateien, die wir haben, jetzt auch die Bilder anzeigen, sodass wir hier eine kleine Vorschau haben.
Eine Grundkarte haben wir drin. Sogar zwei Grundkarten zur Auswahl. Fügen wir jetzt mal ein Kartenthema hinzu bzw. füllen dieses leere Default-Kartenthema mit Daten. Ich klappe das mal alles ein bisschen zusammen, damit es ein bisschen übersichtlicher wird. Zuerst müssen wir hier auch wieder eine ID vergeben. Wir lassen hier auch die Null.
Wir geben hier einen internen Namen. Ich nenne das Ganze jetzt mal Test. Und als externen Namen auch Test. Wir können hier ein Icon-Name mitgeben. Wir nehmen hier einfach mal das Thema oder den Namen Globe, sehen wir gleich, wie das aussieht.
Und wir können jetzt die Vektor- und Rasterlayern zufügen. Deswegen fangen wir damit erst mal an. Als ID geben wir hier einfach mal ein 10 vor. Und wir brauchen einen internen Namen. Das Ganze nehmen wir hier in dem Fall einfach mal Länder. Denn das werden Ländernamen sein, die wir hinzu... Länder kennen sind, die wir hinzufügen. Und wir müssen hier auch dann
den Rastertype hier auswählen. In dem Fall melden wir einen BMS machen. URL an. Base URL. Das sind Daten vom Deutschen Wetterdienst. Als CAS wird für die Kartentastellung EPSG 3857 genutzt. 4326 würde auch gehen. Wird allerdings mit einer Verzerrung einhergehen. Das Style lassen wir einfach mal frei. Dann wird der Default-Style gezogen.
Als Format der Rückgabe nehmen wir Image PNG. Version des WMS ist die 1.3.0. Und wir müssen noch Width und Height angeben. Und zwar wird hier standardmäßig die Kacheln in 256... bei 256 großen Bildkacheln abgefragt.
Und dann lässt sich auch wieder ein Image-Namen zufügen. Ich nehme jetzt hier auch wieder Globe. Einfach mal zu einfach als Halber. Ich gestatte das. Und wir sehen, dass wir jetzt hier diese gelbe Umrandung... und den Ländergrenzen haben.
Wir fügen noch einen zweiten. Einen zweiten Layer hinzu. Auch hier kann man wieder, im Grunde genommen, die Konfiguration... die man schon einmal gemacht hat, erst mal... kopieren und einfügen. So als Basis. Erhöhen jetzt den Zähler für die ID. Vergeben wir einen internen Namen. Und auch hier haben wir wieder ein BMS drin.
Das sind wieder Daten vom Deutschen Wetterdienst. Erstatten das Ganze wieder. Sehen wir hier erst mal noch nicht so viel. Das liegt aber daran, dass Warnungen auf See... in der nördlichen Nordsee zu finden sind. Und da haben wir nämlich den nächsten Layer. Und wenn wir nämlich hier auf die Kappen-Inhalte gehen...
sehen wir auch gleich, dass wir das Ganze anschalten... und ausschalten können. Kommen wir jetzt zum Thema der Objektabfrage. Dafür brauchen wir kein Raster-Layer, sondern einen Vektor-Layer. Dafür haben wir einen Platzhalter drin. Wir geben hier auch wieder eine ID. Jetzt haben wir einen internen Namen.
Das nenne ich jetzt mal Warnungen-Info. Wir müssen angeben, zu welchem Raster-Layer das Ganze gehört. Innerhalb des Kappenthemas, in dem wir uns hier befinden. Das sind die Warnungen auf See. Das hat die ID 11. Wir sagen noch, was für ein Daten-Typ oder Datenquelle das Ganze hat... um die Annotation anzuzeigen.
Das kann ein lokaler File sein, ein Remote-File oder ein BFS. In dem Fall machen wir hier mal einen lokalen File. Denn wir können auch Daten lokal mitgeben. Das habe ich schon mal vorbereitet. Einfach eine GeoJSON-Datei. Die sieht so aus. Nicht sonderlich spektakulär. Und die können wir einfach in das Xcode-Projekt hineinziehen.
Unter Local Data. Und übergeben wir diesen Namen hier einfach in die Konfiguration hier rein. Wir müssen also noch nicht mal Punkt GeoJSON machen... und wirklich nur den Namen. Wir haben Gebiet des CS Centroids. Und wir müssen jetzt noch mitteilen...
wie wir die Sachdaten abfragen wollen. Auch hier wieder die Base URL. In welcher Version liegt das Ganze vor? Null. Und CRS ist hier jetzt die Ausnahme. Dass wir das über 4, 3, 2, 6 machen. Nicht über 3, 8, 5, 7. Ganz wichtig. Das hat einfach etwas mit der Koordinatentransformation...
innerhalb der App zu tun. Mit 4, 3, 2, 6 müssen wir die nicht erst transformieren... was die Laufzeit ein bisschen vereinfacht. Format Image slash PNG. Als Carry Layers nehmen wir auch wieder Warnung auf C. Das ist genau das gleiche Info-Format.
Nehmen wir hier in dem Fall Application JSON. Feature-Con können wir auch einstellen. Wir sagen, dass wir maximal 10 Objekte zurück haben wollen. Vieles lassen wir einfach mal leer. Und müssen jetzt noch, ganz wichtig, das Styling konfigurieren. Einmal, wie die Annotations aussehen sollen.
Und wie dann, wenn ein Objekt gehighlightet wurde, selektiert wurde, wie das aussehen soll... bezüglich der Außenlinie und der Füllung. Die Farbe müssen wir noch anlegen, und zwar in den Assets. Eine ganz reiche Sache. Gehen wir einfach bei Rechtsklick rein. Sagen New Color Set.
Und dann können wir einfach hier sagen, wie die Farbe aussehen soll. Dann können wir auch Show. Dann können wir das hier wunderbar aussuchen. Wir können das auch über so einen Farbkreis machen. Ich mache einfach mal ein kleines Lila rein. Und benennen die Farbe noch entsprechend um.
So wie wir sie in der Konfiguration nutzen. Wir nennen das jetzt Test Color. Und können das Ganze jetzt starten. So, jetzt haben wir die Warnungen auf C hier. Also Annotations an. Können Sie uns anklicken.
Dann wird einfach das Get Feature Info Request abgesetzt. Und das Ganze gehighlightet in der Farbe, wie wir es konfiguriert haben. Und wir können das Ganze hier auch groß machen. Und sehen dann alle Daten, die das Service dann uns zurückgibt. Da sind wir wieder bei den Folien. Und damit eigentlich auch am Ende meines Vortrages. Ich bin noch nicht ganz fertig mit der Entwicklung bis zur Version 1.0.
Was fehlt ist vor allem die WFS-Integration. Und das Thema Push-Mitteilungen. In Zukunft möchte ich dann eigentlich auch noch OTC API Features unterstützen. Und auch das Thema Vector Details angehen. Denn mit Vector Details kann man natürlich eine wunderbare Offline-Fähigkeit gewährleisten. Das Projekt selber ist veröffentlicht unter Apache 2.0.
Das heißt frei verfügbar unter GitHub. Hier der Link auch dazu. Wer Fragen hat, Anregungen oder einfach mit mir in Kontakt treten möchte, ist hier auch mal meine E-Mail-Adresse. Oder geht einfach unter GitHub in das Projekt rein. Dort gibt es auch ein Discussion Board. Insofern kann ich mich nur für Ihre Aufmerksamkeit bedenken. Und auf Wiedersehen. Ciao.
Danke Christoph Jung für diesen interessanten Vortrag. Und diese wirklich sehr elegante App, die du hier gezeigt hast. Eine wichtige Frage hast du bereits im Chat beantwortet. Und jetzt auch noch auf der letzten Folie. Nämlich ist es Open Source und gibt es einen Quake-Code dazu. Der Link ist bereits im Chat da.
Das ist Open Source. Und dann kam eine interessante Doppelfrage. Nämlich zuerst nach dem Namen. Wer kommt der Name Malinki? Und wird es die App auch für Android geben? Genau, also der Name ganz schnell gemacht. Also mein Nickname auf GitHub ist Jagutki.
Das ist polnisch für Blaubeeren. Da gibt es ein kleines Kinderlied für. Und ich bin einfach in der Namenskonvention geblieben. Malinki ist dann einfach Himbeeren auf Polnisch. Die App gibt es erst mal nur für iOS. Mein Ziel wäre auch, dass es für Android noch gibt. Zwei Limitierungen gibt es da an der ganzen Sache natürlich. Erstens, ich muss zugeben, ich bin ein Apple-Haushalt.
Also mir fehlt gerade das physische Gerät. Und damit auch der Zwang, sozusagen die App selbst konsumieren zu können. Das Zweite ist, es ist ein Freizeitprojekt. Also ich bin noch ganz gut ausgelastet, erst mal Version 1.0 für iOS zu bringen. Und dann müsste ich halt ins Thema Android-Entwicklung rein. Und dann dort machen. Insofern ist Stand jetzt noch nicht geplant.
Wäre schön, wenn ich es hinbekomme. Vielleicht lieber auch mehr so in den Wegen Richtung Progressive-Web-App. Dass man das dann für Android nutzt. Mal schauen. Und da gibt es gerade noch die Anschlussfrage. Die Erstellung ist North of the Mac möglich? Momentan ja, weil es ein Xcode-Projekt ist. Also man könnte ja für iOS theoretisch auch,
wenn man Qt entwickelt beispielsweise, das auch unter Windows machen. Aber spätestens dann beim Kompilieren der App. Weil der Kompilierungsschritt zwingend notwendig ist, bevor man die dann die App hochladen kann in den App-Store oder dann auch verteilen kann in-house dann auf mobile Geräte bei den Kolleginnen und Kollegen. Der muss dann immer noch auf eine Mac erfolgen.
Eine weitere Frage. Kann man die aktuelle GPS-Position anwenden? Momentan nicht. Ist allerdings 1-2 Zeilen-Code. Also das habe ich ja noch vor. Ist aber, weil es so ein einfaches Feature ist, dann noch für ausstehende Aufgaben offen. Dann vielleicht noch eine Frage von mir. Wie steht es um die Offline-Fähigkeit?
Du hast da einen Offline-Jason gezeigt. Aber was passiert allgemein, wenn man mal offline ist? Geht gar nichts mehr oder? Also bei den Sachen oder anders. Wenn ich offline bin und die App starte und ich will ein BMS oder ein DMTS oder ein TMS und jemand anfragen, dann zeige ich mir bitte nicht.
Dann bin ich abgefragt und bin gerade in einem Funkloch. Dann wird er natürlich die gecachehten Daten. Momentan geht es auch so, dass ich Blüktramiten als TMS auch auf dem Gerät mit ablegen kann. Da gibt es die Limitierung. Ich weiß jetzt gerade gar nicht,
die Anzahl noch maximal 4 GB, die eine App groß sein durfte, bevor man sie hochlädt in den App-Store. Und zukünftig, dass ich dann die Vector-Tiles mit integrieren möchte. Und wenn man das hat, hat man diesen ja doch viel groß auf dem Gerät. Dann hätte man wahrscheinlich die Chance,
einen Offline-Client zur Verfügung zu stellen. Passend zur Frage, bist du jetzt auch gerade in einem Funkloch geraten. Aber man hat es, glaube ich, einigermaßen verstanden. Vielen Dank. Interessanter Vortrag. Fragen könntest du alle beantworten.
Wir machen jetzt eine größere Pause. Um 11 Uhr geht es hier weiter wieder mit OpenJares.