Latest Contributions by NiklasKöhn

An alternative address system comes to the rescue where good old postal addresses cannot help. Now for ArcGIS Experience Builder.    A Bavarian parks his car at ///psyches.army.truck and enters the headquarters of Esri Germany in ///perceptions.retakes.somebody. This situation could just as well be described as: A Bavarian parks his car at Raiffeisenstr. 16 and enters the headquarters of Esri Germany in Ringstr. 7. Is similar, even if he would probably have to turn around a few times to find the right building and the entrance door.   It gets complicated when he has not driven his tractor home after 8 ‘Maß’ of beer at the village fair, but has parked it in the field. The next morning, he now tries to remember the amount and location of the bushes along the way in order to find his vehicle again. Had he had a very specific app handy in the moment he got out, he could have simply looked up the location: Clearly, he didn't make the turn around the forest on the way home from Kranzberg to Sünzhausen and left the tractor at ///failsafe.renowned.cluttered to be on the safe side.   This is how it turns out when you sit in your office at ///sector.dared.madder and try to imagine a real-life situation of a typical inhabitant of the extended Munich surroundings. In this case, it doesn’t matter how realistic the description is. What’s important is that a spot on earth without an address has been unambiguously designated and made retrievable. Transferred to life in civilization the case could arise that a delivery is expected in my office. The main entrance is in ///grab.secretly.tractor, but better parking is in the courtyard and the entrance there is in ///wedding.scrap.bossy. The address for both points is equally Konrad-Adenauer-Ufer 41-45.  An "Artist" sign desparately indicates the way to the stage at a highway exit What is all this about? Concert promoter Chris Sheldrick had the same problem: delivery points for equipment or entrances for artists are not describable with postal addresses. Festivals take place in large areas, and outside densely populated areas, there is no dense network of streets and house addresses. Together with mathematician Mohan Ganesalingam he looked for an idea to make every place in the world addressable and developed the alternative address system what3words. This system covers the entire globe in a 3x3 meter grid and uses a sophisticated algorithm to assign each square a unique address consisting of three words. In contrast to geographic coordinates, such as used by a GPS system, the resulting designations are memorable and easy to convey even in natural language.   The words are chosen in a way that inner-city addresses are described by shorter words and similar combinations are as far apart as possible. Even if there are doubts as to whether the measures taken for acoustic differentiation are sufficient for the system to be used in safety-critical areas, it's already finding a broad user base: Mercedes Benz was the first car manufacturer to come aboard in 2017. A look at the Products page on the official website shows that the system has since found its way into the vehicles of numerous other manufacturers, but is also being used by companies in the fields of mobility, logistics, sports, security and, of course, map, GIS and CAD providers.   what3words is thus included in so-called embedded systems, i.e. permanently installed systems such as navigation systems in vehicles. Other implementations bring the squares as a plugin into existing software products, among which are planning tools for desktop workstations or mobile apps for localizing missing paragliders or for drone control. A dedicated mobile map app is also available that locates the device via GPS and places it in the appropriate grid cell on the map.    For developers, what3words can be used in a variety of ways: The REST API enables a connection to all systems that can communicate via HTTP. In addition, there are libraries for the most common programming languages, which simplify the handling of the REST API. Among the GIS extensions there is also an implementation as ArcGIS Locator Service. All programming interfaces can be used via API key and tested with a free plan.  The what3words GeocodeServer comes in versions for every available language and also in a combined variant. It can be hooked into ArcGIS desktop software as well as into an ArcGIS online organization or an ArcGIS Enterprise installation. Via the Locator module of the ArcGIS API for JavaScript, the URL of the respective GeocodeServer can also be used directly in the code. Step-by-step instructions can be found on the what3words website. In addition, the company offers numerous programming examples in different languages on its GitHub account, including the ArcGIS API for JavaScript.  The what3words-Widget in an ArcGIS Experience   Now we need to know how to easily integrate the system into a web application. Fortunately, the ArcGIS Experience Builder Developer Edition is an extensible, configurable WYSIWYG application for WebGIS apps. The Experience Builder runs on the JavaScript-based server Node.js, which brings the Node Package Manager (NPM) to load external dependencies from the Internet. A package just like this is provided by what3words to use its REST API. We took advantage of this to develop a widget, which is freely available on GitHub.  Clicking on the map sends the click point as a coordinate to the REST API and gets back a response object in GeoJSON format containing the vertices of the square and of course the three-word address, among other information. From this response, the square is drawn on the map and the widget is filled with data. The wrapper in the NPM package of what3words is mostly correctly typed and is therefore comfortable to use with TypeScript. Here is a snippet from the TypeScript Definitions that defines the response object:   export interface LocationProperties {       country: string;       nearestPlace: string;       words: string;       language: string;       map: string;   }   export interface LocationGeoJsonResponse {       bbox: [number, number, number, number];       geometry: {           coordinates: number[];           type: string;       };       type: string;       properties: LocationProperties;   }  In the backend of the Experience Builder, which is the configuration page used to assemble your app out of data sources and widgets, the what3words widget offers a wide range setting options. As usual, a connection to a map widget needs to be established in order to retrieve the click point and visible extent and to draw on the map in return. The aforementioned API Key is stored here and used in the background for every request to the REST API.     When the backend is initialized, it queries the shortcodes of all available languages at what3words. The setting affects the language of the three-word address on the widget and on the map. Other settings are related to the map display as well as the widget display and behavior.   The REST API provides a function to return the grid, but in maximum 4x4 km size. The widget reacts to the zoom level of the map view and checks the geodesic distance of two vertices in larger scales. If it falls below 4 km, the grid is downloaded and created as a client-side FeatureLayer. Numerical values are assigned to all lines, increasing continuously from the click point to the edge of the image. A renderer visualizes a grid based on these values, which appears in what3words' own red at the edge of the image and becomes lighter and more transparent towards the click point.   The what3words widget supports all languages supported by the what3words REST API. There are a number of ideas for the future development of the widget: We want so integrate a search functionality by text input, meaning the geocoding of a three-word address. In order not to have to implement a suggestion function manually but to use the Search widget of the ArcGIS API for JavaScript for this purpose, this function could be implemented by using the ArcGIS Locator Services instead of the REST API. Other ideas include converting selected vertices or point features to three-word addresses, or checking which features are in the 3x3 meter square hit by click.    The source code is publicly available on GitHub. If you want to participate, please fork the repository and send a merge request after developing a new feature. Feel free to use the discussion functions on GitHub or here on Esri Community! We’re looking forward to your ideas and maybe even productive uses of the widget!     Here you can find a German version of this article. Please follow me and GeoDevGermany on Twitter if you liked this content. ... View more

Ein alternatives Adresssystem hilft, wo herkömmliche Postadressen versagen. Jetzt auch im ArcGIS Experience Builder.    Parkt ein Bayer sein Auto an ///energische.geduld.wolle und betritt das Hauptquartier von Esri Deutschland in ///poesie.schenken.backofen. Diese Situation könnte man ebensogut beschreiben mit: Parkt ein Bayer sein Auto an der Raiffeisenstr. 16 und betritt das Hauptquartier von Esri Deutschland in der Ringstr. 7. Ist ähnlich, auch wenn er sich für das Finden des richtigen Gebäudes und der Eingangstür vermutlich ein paarmal um sich selbst drehen müsste.  Kompliziert wird es, wenn er seinen Traktor nach 8 Maß auf dem Dorffest nicht mehr nach Hause gefahren, sondern im Acker geparkt hat. Am nächsten Morgen versucht er sich nun an die Anzahl und Ausrichtung der Büsche am Weg zu erinnern, um sein Fahrzeug wiederzufinden. Hätte er kurz eine ganz bestimmte App zur Hand gehabt, hätte er sich beim Aussteigen eine Erinnerung setzen können: Ganz klar, er hat auf dem Heimweg von Kranzberg nach Sünzhausen die Kurve ums Waldstück nicht geschafft und den Traktor sicherheitshalber bei ///jedoch.trennt.genauigkeit stehenlassen.  So geht das aus, wenn man in ///zeit.ursache.bringen im Büro sitzt und versucht, sich eine lebensnahe Situation eines typischen Bewohners des erweiterten Münchner Umlands vorzustellen.  Auf den Realitätsgehalt der Begebenheit kommt es in diesem Fall nicht an. Wichtig ist, dass mit dem Standort im Acker ein adressenloses Fleckchen Erde eindeutig bezeichnet und wiederauffindbar gemacht wurde. Übertragen auf das Leben in der Zivilisation könnte sich der Fall ergeben, dass in meinem Büro ein Speditionslieferung erwartet wird. Der Haupteingang befindet sich in ///worunter.flair.zeilen, besser parken kann man aber im Innenhof und der dortige Eingang ist in ///berichten.ausstieg.erlassen. Die Adresse lautet für beide Punkte gleichermaßen Konrad-Adenauer-Ufer 41-45.  Ein "Artist"-Schild weist verzweifelt den Weg Richtung Bühne an einer Autobahnauffahrt Was soll das alles? Konzertveranstalter Chris Sheldrick hatte dasselbe Problem: Lieferorte für Ausrüstung oder Einfahrten für Künstler sind mit postalischen Adressen nicht beschreibbar. Festivals finden nun mal auf großen Flächen statt, und außerhalb dicht besiedelter Gebiete findet man auch kein dichtes Netz von Straßen und Hausadressen. Also suchte er nach einer Idee, jeden Ort der Welt adressierbar zu machen und entwickelte zusammen mit dem Mathematiker Mohan Ganesalingam das alternative Adresssystem what3words. Dieses legt ein 3x3-Meter-Raster über den gesamten Globus und weist jedem Quadrat über einen ausgetüftelten Algorithmus eine eindeutige Adresse, bestehend aus drei Wörtern zu. Im Gegensatz zu geographischen Koordinaten, wie sie beispielsweise ein GPS-System ausgeben könnte, sind die resultierenden Bezeichnungen einprägsam und auch in natürlicher Sprache gut zu transportieren.  Die Wörter werden so gewählt, dass innerstädtische Adressen kürzere Wörter zugewiesen bekommen und ähnlich lautende Kombinationen möglichst weit auseinanderliegen. Auch wenn es vereinzelt Zweifel daran gibt, dass die getroffenen Maßnahmen zur akustischen Unterscheidung ausreichen, um das System in sicherheitskritischen Bereichen einzusetzen, findet es bereits eine breite Anwenderschaft: Als erster Autohersteller kam 2017 Mercedes Benz ins Boot. Ein Blick auf die Products-Seite der offiziellen Website zeigt, dass das System seitdem in die Fahrzeuge zahlreicher anderer Hersteller Einzug gehalten hat, aber auch von Unternehmen aus den Bereichen Mobilität, Logistik, Sport, Sicherheit und natürlich auch Karten-, GIS- und CAD-Anbietern genutzt wird.  what3words ist also in sogenannten Embedded Systems, also fest verbauten Systemen wie Navigationssystemen in Fahrzeugen, enthalten. Andere Implementierungen bringen die Quadrate als Plugin in bestehende Software, seien es Planungstools für den Desktop-Arbeitsplatz oder mobile Apps zur Lokalisierung von vermissten Paraglidern oder zur Drohnensteuerung. Eine eigene mobile Karten-App ist ebenfalls verfügbar, die das Gerät über GPS verortet und in der entsprechenden Rasterzelle lauf der Karte platziert.   Für Entwickler ist what3words vielfältig nutzbar: Die REST API ermöglicht eine Anbindung an alle Systeme, die über HTTP kommunizieren können. Dazu gibt es Bibliotheken für die gängigsten Programmiersprachen, die den Umgang mit der REST API vereinfachen. Unter den GIS-Erweiterungen findet sich auch eine Umsetzung als ArcGIS Locator Service. Alle Programmierschnittstellen können per API-Key genutzt und mit einem kostenlosen Plan getestet werden.  Der what3words GeocodeServer kommt in Ausführungen für jede verfügbare Sprache daher und auch in einer kombinierten Variante. Er kann in ArcGIS-Desktop-Software wie auch in einer ArcGIS-Online-Organisation oder einer ArcGIS-Enterprise-Installation eingehangen werden. Über das Locator-Modul der ArcGIS API for JavaScript kann die URL des jeweiligen GeocodeServers auch direkt im Code verwendet werden. Eine Schritt-für-Schritt-Anleitung findet sich auf der Website von what3words. Zusätzlich bietet das Unternehmen auf seinem GitHub-Account zahlreiche Programmierbeispiele in unterschiedlichen Sprachen, dabei auch die ArcGIS API for JavaScript.  Das what3words-Widget in einer ArcGIS Experience   Was wir nun noch brauchen, ist die einfache Einbindung des Systems in eine Webanwendung. Zum Glück gibt es mit dem ArcGIS Experience Builder Developer Edition eine erweiterbare, konfigurierbare WYSIWYG-Applikation für WebGIS-Apps. Der Experience Builder läuft auf dem JavaScript-basierten Server Node.js, der den Node Package Manager (NPM) mitbringt, um externe Abhängigkeiten aus dem Internet zu laden. Ein eben solches Paket bietet what3words zur Nutzung seiner REST API. Dieses haben wir uns bei der Entwicklung eines Widgets zunutze gemacht, das frei auf GitHub verfügbar ist.  Ein Klick auf die Karte schickt den Klickpunkt als Koordinate an die REST API und bekommt ein Antwortobjekt im GeoJSON-Format zurück, das unter anderem die Eckpunkte des getroffenen Quadrats und natürlich die Dreiwort-Adresse enthält. Aus diesen Informationen wird das Quadrat auf die Karte gezeichnet und das Widget mit Informationen gefüllt. Der Wrapper im NPM-Paket von what3words kommt weitgehend korrekt typisiert daher und ist deshalb mit TypeScript komfortabel anwendbar. Hier ein Ausschnitt aus den TypeScript Definitions, der das Antwortobjekt definiert:  export interface LocationProperties {       country: string;       nearestPlace: string;       words: string;       language: string;       map: string;   }   export interface LocationGeoJsonResponse {       bbox: [number, number, number, number];       geometry: {           coordinates: number[];           type: string;       };       type: string;       properties: LocationProperties;   }  Im Backend des Experience Builders, also der Konfigurationsseite, mit der man aus Datenquellen und Widgets seine App zusammenstellt, bietet das what3words Widget zahlreiche Einstelloptionen. Wie üblich muss eine Verbindung zu einem Kartenwidget hergestellt werden, um den Klickpunkt und sichtbaren Extent entgegenzunehmen und im Gegenzug auf die Karte zeichnen zu können. Der bereits erwähnte API Key wird hier hinterlegt und im Hintergrund bei jeder Anfrage an die REST API verwendet.  Das Backend des what3words-Widgets   Direkt beim Start des Backends werden die bei what3words verfügbaren Sprachen abgefragt. Die Einstellung wirkt sich auf die Sprache der Dreiwortadresse aus, die im Widget und auf der Karte erscheint. Weitere Einstellungen beziehen sich auf die Kartenanzeige sowie die Anzeige und das Verhalten des Widgets.  Die REST API bietet eine Funktion zur Rückgabe des Grids, aber in maximal 4x4 km Größe. Das Widget reagiert auf die Zoomstufe der Kartenansicht, prüft in größeren Maßstäben den geodätischen Abstand zweier Eckpunkte. Unterschreitet er 4 km, wird das Grid heruntergeladen und als clientseitiger FeatureLayer angelegt. Dabei werden allen Linien Zahlenwerte zugewiesen, die vom Klickpunkt zum Bildrand hin kontinuierlich ansteigen. Ein Renderer visualisiert anhand dieser Werte ein Grid, das am Bildrand im what3words-eigenen Rot erscheint und zum Klickpunkt hin heller und transparenter wird.  Das what3words-Widget unterstützt alle Sprachen, die auch die what3words REST API unterstützt. Für die zukünftige Weiterentwicklung des Widgets gibt es eine Reihe an Ideen: Naheliegend ist natürlich die Suche per Texteingabe, also die Geokodierung einer Dreiwort-Adresse. Um eine Vorschlagsfunktion nicht manuell umsetzen zu müssen, sondern dafür das Search-Widget der ArcGIS API for JavaScript einzusetzen, könnte man diese Funktion per ArcGIS Locator Services umsetzen, anstatt die REST API zu verwenden. Weitere Ideen sind, selektierte Vertices oder Punkt-Features in Dreiwort-Adressen umzuwandeln oder zu prüfen, welche Features in dem per Klick getroffenen 3x3-Meter-Quadrat liegen.   Der Quellcode liegt öffentlich auf GitHub. Wer sich beteiligen möchte, kann einen Fork erstellen und nach Entwicklung eines neuen Features einen Merge Request schicken. Nutzt auch gerne die Diskussionsfunktionen auf GitHub oder hier in der Esri Community! Wir sind gespannt auf eure Ideen und vielleicht sogar produktive Einsatzzwecke des Widgets!    Hier gibt's eine englische Version dieses Artikels. Please follow me and GeoDevGermany on Twitter if you liked this content. ... View more

Beim Hochziehen einiger NPM-Pakete in ExB 1.8 Widgets bin ich über das Problem gestolpert, dass Webpack 5 keine Polyfills für Node Core Modules mehr beinhaltet. Das äußert sich in der Fehlermeldung "BREAKING CHANGE: webpack < 5 used to include polyfills for node.js core modules by default", un dat heiß op hoochdeutsch: Pakete, die Kernfunktionen von node.js verwenden, funktionieren nicht mehr nativ mit Webpack 5.   Auf der Suche nach einer Erklärung erschien mit folgende plausibel: "Webpack 4 automatically polyfilled many Node APIs in the browser. This was not a great system, because it could lead to surprisingly giant libraries getting pulled into your app by accident, and it gave you no control over the exact versions of the polyfills you were using. So Webpack 5 removed this functionality." (Quelle)   Beschreibungen zur Abhilfe finden sich viele, direkt in den Fehlermeldungen in der Konsole und auch unter o.g. Quelle: Die benötigten Quellen müssen in der webpack.config unter resolve.fallback eingetragen und per 'npm i' installiert werden.   So weit so schön. Nur ist diese Konfiguration im ExB zerhackt und auf mehrere Dateien verteilt worden:   Von links nach rechts: webpack.config.js im "client" Root-Ordner referenziert webpack-extensions.config.js im Unterordner "webpack" webpack-extensions.config.js bastelt sich die Config aus Referenzen zu webpack-extensions.common.js zusammen in webpack-extensions.common.js kommt das resolve-Objekt an 3 Stellen vor, nämlich in getTemplatesWebpackConfig(), getWidgetsWebpackConfig() und getThemesWebpackConfig(). Hier wird die Property fallback eingetragen, deren Inhalte (analog zu den anderen Props) in webpack.common.js eingetragen werden. in webpack.common.js schließlich stehen die Referenzen auf die "einzufüllenden" Pakete unter exports.fallback. Dat funzt.   Blöd daran ist, dass die Webpack-Dateien auf Root-Ebene des "client"-Ordners nicht im Code-Repository stehen, sondern mit dem ExB geliefert werden. Der ExB bietet ja genau den Vorteil, eigene als "exb-web-extension-repo" markierte Git-Repos einhängen zu können, und so nur den eigenen Quellcode in der Quellcodeverwaltung zu haben (ohne irgendwelche wilden Kopier-Vorgänge in den Build-Prozess einzuhängen wie vor Jahren mit Gulp für WebApp-Builder-Projekte von uns umgesetzt). Verwendet man nun in seinen Custom Widgets NPM-Pakete, die Polyfills benötigen, muss man an die Webpack-Configs, die aber nicht im Repo stehen.   Meine Lösung: Ich habe in meinem Repository einen Unterordner namens "_webpack5-config-updates" angelegt, der als ersten Commit die originalen mitgelieferten Configs enthielt. Im zweiten Commit sind dann meine Ergänzungen, sodass man auch noch nachvollziehen kann, was sich denn getan hat.   Das wird genau dann wichtig, wenn man mehrere Repos einbinden, die jeweils ihre eigenen Polyfills benötigen. Denn dann muss man sich die Configs manuell anschauen und alle benötigten Polyfills in die Webpack-Configs im "client"-Ordner aufnehmen Genau das ist auch der Grund, warum die Lösung nicht so richtig cool ist.    Wer hier Ideen hat - bitte gerne melden und diskutieren!   ... View more

You should really provide a timezonesetting right on the schedule page of each virtual Esri event‌, like the virtual uc‌ right here: https://userconference2020.schedule.esri.com/schedule. This would allow people in Europe, Asia etc. - who are on the other side of the world - to see right away, which events they will be able to attend live. Furthermore, events that are NOT going to be recorded should labelled. timezone ... View more