SAPOS GPS Korrektursignal per DAB+ empfangen - SSRoverDAB+auswerten?

Communities Deutschland (Germany)
, , ,
1

Hi, auf der diesjährigen FOSSGIS Konferenz wurde u.A. vorgestellt, dass das Korrektursignal für Hochgenaue Positionierung im Zentimeterbereich nun nicht nur kostenlos per NTRIP-Server verbreitet wird, sondern auch per Rundfunk DAB+.

Einige hatten da bereits angeregt, dass es mittels “Software Defined Radio” doch eigentlich möglich sein sollte, das mit relativ einfachen Empfängern auszuwerten und so die aktuell recht preiswert gewordenen RTK GNSS Empfänger auch ohne permanenten Internetempfang mit den Korrekturen in Echtzeit (PPP) zu versorgen.

Ich hatte dann einfach mal bei der RTKlib eine entsprechende Erweiterung angeregt und auf dem Fediverse gefragt, ob es jemand mit Erfahrung in dem Bereich gibt. Ein Amateurfunker hat sich dann auch gleich der Sache verschrieben und etwas experimentiert, so dass aus dem DAB+ Datenstrom des Bundesmix schon die Korrekturen herausfallen.

Nun werden aber noch ein paar Mitstreiter gesucht, welche sich mit einbringen wollen, wie man das mit der SSRZ Python Demo verbandeln kann und wie man das in das bestehende Ökosystem integrieren kann, so dass man vielleicht in Zukunft auch mit einem RPI+DVB-T USB Stick + RTK GPS eine hochgenaue Lagegenauigkeit hätte :partying_face:

1 Like
2

Hmm, ob das wirklich klappen kann? Soweit ich weiß, gelten SAPOS-Daten doch jeweils nur in einem begrenzten Bereich: das LVermAmt muss insofern wissen, für welchen sie bereitgestellt werden sollen. Wie bekommt sie diese Info denn per DAB?

Rätselt

tracker51

Nachtrag: Ich werde demnächst beim Wandern mal ein paar hundert Gramm in Form eines kleinen DAB-Radios mitschleppen, um mal zu testen, ob an Funkloch-Stellen (=keine NTRIP-Daten empfangbar) tatsächlich DAB-Empfang möglich ist …

1 Like
3

@tracker51: Hier einige Fragen zu deinem Setup:

  • Könntest du dein RTK-Setup (HW, SW) mal näher beschreiben?
  • Welche Lage- und Höhengenauigkeit erreichst du damit?
  • Welche Ergebnisse erreichst du, wenn du einen Track (Wandern) damit aufzeichnest?
4

Möchtest Du das wirklich? Na gut, das haste nun davon :wink::

Das System besteht aus:

  1. einem Smartphone und
  2. dem RTK Portable Bluetooth Kit von ArduSimple (inkl. Antenne von ublox) für 275,- € + MWSt .
    Zusätzlich benötigt man
  3. einen NTRIP-Client fürs Smartphone (ich nutze dafür die kostenlose Lefebure-App) und
  4. einen SAPOS-Zugang beim jeweiligen Landesvermessungsamt [LVermA], um von dort die Korrekturdaten zu erhalten. Dieser Zugang ist in allen Bundesländern quasi ebenfalls kostenlos; einige Länder verlangen aber Registrierungsgebühren.

Zum Betrieb muss der RTK-Empfänger natürlich an eine Stromquelle angeschlossen werden - ich nutze dafür eine kleine Powerbank… Die Antenne wird mit einem kleinen SMA-Stecker ebenfalls mit dem Gerät verbunden und sollte so positioniert werden, dass sie möglichst freie Sicht in alle Himmelsrichtungen hat; für Freaks (so wie mich) gibt’s von Trimble eine spezielle Baseball-Cap, die ein eingearbeitetes Fach für so eine Antenne hat. Mit den Default-Einstellungen des Geräts sollte sofort Betrieb möglich sein.

Im Smartphone ist unter Einstellungen → System → Entwickleroptionen (dort ganz nach unten scrollen) bei “App für simulierte Standorte auswählen” (mock location) der genutzte NTRIP-Client einzutragen, der nach Installation der gewählten App (bei mir also Lefebure) dort auch schon angezeigt wird. Weiterhin sind auf dem Smartphone “Standort” und “Bluetooth” zu aktivieren.

In der App selbst sind die Zugangsdaten des jeweiligen LVermA einzutragen.

Und dann kann’s auch schon losgehen (Beschreibung gilt für Nutzung der Lefebure-App!): dort einfach nur auf “Connect” tippen, und schon werden die vom (natürlich vorab durch Anschluss der Stromversorgung eingeschalteten) Empfänger ermittelten Positionen ausgegeben und und gleichzeitig im Ordner “Download” als Text-Datei der Form “NMEA-yyyy-mm-dd.txt” gespeichert. Sobald die Verbindung zum Korrekturdatenserver des LVermA steht, wird der Datenempfang durch ein gelbes Laufband angezeigt (ca. 2 MB/h). Hat man eine Kartenapp (ich nutze OSMAND), kann man sich dort den jeweiligen Standort anzeigen lassen.

Die NMEA-Daten kann man daheim mit dem ebenfalls kostenlosen- Konvertierungsprogramm “GPSBabel” in alle möglichen anderen Formate konvertieren. Bei Nutzung des Kartenprogramms “OSMAND” kann man den Track gleich parallel im gpx-Format aufzeichnen lassen.

Ich bin jedenfalls begeistert von dem Teil. Selbstverständlich erzielt man die o. g. Genauigkeit nur unter guten Bedingungen; bei Regen unter einem geschlossenen Laubdach oder in Funklöchern, wo dann natürlich die Korrekturdaten fehlen, wird man die maximale Genauigkeit aber nicht erreichen.

Und sicherheitshalber: ich bin in keinster Weise mit ArduSimple (sitzt in Spanien) oder Lefebure oder OSMAND oder GPSBabel verbandelt und bekomme nicht das geringste Honorar für diese Zeilen!

Wie gesagt, bei guten Bedingungen ist es zentimetergenau. Ich habe hier mal irgendwo ein Bild gepostet, auf dem ein 10-Hz-Track von einer Radfahrt mitten durch ein Drängelgitter (cycle_barrier) zu sehen ist.

Bevor ich die Lage von Wegen oder Objekten korrigiere, vergleiche ich meine Tracks mit Luftbildern und DTKs der LVermÄmter: bei guten Empfangsverhältnissen sind die dann deckungsgleich …

Uff, geschafft!

Ciao

tracker51

Edit: 2 fehlende Buchstaben ergänzt …

3 Likes
5

Das ist hier erklärt:

https://gepos.sapos.de/

Über DAB werden die Daten für ganz Deutschland ausgestrahlt offensichtlich. Über das SSRZ wird das so “komprimiert” das der mit entsprechend kleinen Bandbreiten auskommt. (Ich hatte erste gedacht das die jeweils die regionalen MUXe im DAB Nutzen um einen Subset auszustrahlen)

D.h. anders als beim normalen SAPOS/NTRIP brauchst du keine Bidirektionale Verbindung.

Problem ist das das SSRZ (Bzw Compact SSR - Japan) zwar Dokumentiert ist aber quasi im Open Source Bereich nicht supported. RTKLIB sieht seit 2013 unmaintained und tot aus.

Es gibt eben von geo++ wohl “umsonst” das Binary für ssr2obs das dann aus dem SSRZ einen RTCM3 feed macht. Damit kannst du dann mit der RTKLIB dein RTK fähigen GPS Empfänger füttern.

Ich habe gestern mal angefangen den RTLSDR zu quälen um mal den Adv SSRZ feed zu extrahieren. Sollte nicht so das Problem sein.

Flo

6

Ach ja - Das problem mit dem RTL-SDR für den DAB Decoder ist das das ziemlich “Stromhungrig” ist - also dadurch das alles in Software eben läuft. Und wer will schon 2kg Batterien mitschleppen.

Ich gab mal (Restmengen) ein DAB Schield für einen RPI:

https://ugreen.eu/product/ugreen-dab-board/

Das basiert auf der Si468x Gruppe an Chips. Die brauchen auch Software, die gibt es auch nicht in Open Source. Ausserdem ist mir nicht klar ob ich an was anderes als definierte Stream Types komme. Das SSRZ im AdV stream ist ja irgendwo in den DAB MCI als Subchannel identifiziert.

Für einen Si4684 hab ich auch schon ein KiCad beispiel gefunden. Da ist tonnen an Audio Amp zeugs mit drauf - Das ist schnell entfernt.

Eine überlegung wäre ein Platinchen zu produzieren mit einem ESP32, ublox X20 modul, und einem DAB Si468x Chip.

Ob der ESP32 genug ist das RTKLIB zeugs ans laufen zu bringen bin ich mir gerade nicht sicher. CPU mässig müsste das reichen.

Und der ESP32 hätte den charmanten Vorteil das der zur not das via WIFI/Bluetooth als GPS “Maus” exportieren könnte.

7

Hi Flo,

danke für die Hinweise:

Ich habe mir dort diesen Flyer mal angeschaut.

Und woher weiß das Korrekturprogrämmchen dann, welchen Datensatz aus dem gesamten komprimierten Datensalat es verwenden muss? Außerdem beziehen sich die Korrekturdaten, wenn ich den Flyer richtig verstanden habe, auf IGS20, während die GNSS-Daten auf WGS84 (fast ETRS89) beruhen: zur Korrektur würde insofern wohl zusätzlich noch eine Koordinatentransformation benötigt.

Andererseits wäre die kostenlose Nutzung der Daten im gesamten Bundesgebiet per Internet (sollen lt. Flyer auch dort angeboten werden) angesichts der nur wenig geringeren erzielbaren Genauigkeit für meine Zwecke durchaus interessant und auch bequemer: im NTRIP-Client wäre dann die Umschaltung auf andere Mountpoints überflüssig …

Schaun mer mal,

tracker51

8

Weil in den SSRZ Daten ALLES drin ist - der NTRIP receiver macht ja nix anderes. Du erzählst dem wo du bist, und der sucht die entsprechende referenzstation. In den SSR Daten ist einfach alles drin.

Das Z für die kompression ist der trick damit du alle referenzstationen mit rein bekommst. Da sah auf den ersten blick so aus als würden die differential coding benutzen in der Annahme das die Unterschiede zwischen den referenzstationen nicht so groß ist.

So tief bin ich aber auch (noch) nicht drin.

Ich vergwaltige gerade welle.io um mir den Datenstrom rauszupumpen.

Flo

9

Ach ja - in dem DR ensemble findet man auch den Stream.

Ich habe einfach einen neuen client neben welle.io und welle-cli aka welle-rtk erzeugt der den ganzen audio/gui/webserver kram nicht enthält.

DAS war gar nicht so wild. Jetzt suche ich gerade wie ich am einfachsten ohne
den welle.io code sehr zu vergewaltigen an den packet stream komme.

Erste versuche haben nur nette coredumps geworfen …

Ensemble label: DR Deutschland  
  [0xd75b] KLASSIK RADIO     [component 0 ASCTy: DAB+ ] [subch 6 bitrate:72 at SAd:192]
  [0x15dc] SUNSHINE LIVE     [component 0 ASCTy: DAB+ ] [subch 21 bitrate:72 at SAd:330]
  [0xd01c] radio horeb       [component 0 ASCTy: DAB+ ] [subch 5 bitrate:48 at SAd:156]
  [0x1a64] ERF Plus          [component 0 ASCTy: DAB+ ] [subch 2 bitrate:64 at SAd:0]
  [0xd210] Dlf               [component 0 ASCTy: DAB+ ] [subch 10 bitrate:104 at SAd:480] [component 1 ASCTy: DAB ] [subch 14 bitrate:32 at SAd:836]
  [0xd220] Dlf Kultur        [component 0 ASCTy: DAB+ ] [subch 11 bitrate:112 at SAd:584] [component 1 ASCTy: DAB ] [subch -1 bitrate:0 at SAd:0]
  [0xd230] Dlf Nova          [component 0 ASCTy: DAB+ ] [subch 12 bitrate:104 at SAd:696] [component 1 ASCTy: DAB ] [subch -1 bitrate:0 at SAd:0]
  [0xd240] DRadio DokDeb     [component 0 ASCTy: DAB+ ] [subch 13 bitrate:48 at SAd:800] [component 1 ASCTy: DAB ] [subch -1 bitrate:0 at SAd:0]
  [0x100d] Schwarzwaldradio  [component 0 ASCTy: DAB+ ] [subch 7 bitrate:64 at SAd:246]
  [0x1a45] ENERGY            [component 0 ASCTy: DAB+ ] [subch 4 bitrate:72 at SAd:102]
  [0x10c3] SCHLAGERPARADIES  [component 0 ASCTy: DAB+ ] [subch 20 bitrate:64 at SAd:288]
  [0x17fa] Absolut relax     [component 0 ASCTy: DAB+ ] [subch 3 bitrate:72 at SAd:48]
  [0x15dd] RADIO BOB!        [component 0 ASCTy: DAB+ ] [subch 22 bitrate:72 at SAd:384]
  [0xe0d00250] DRadio Daten      [component 0 ASCTy: DAB ] [subch -1 bitrate:0 at SAd:0]
  [0xe0d110bc] EPG Deutschland   [component 0 ASCTy: DAB ] [subch -1 bitrate:0 at SAd:0]
  [0xe0d010bc] TPEG              [component 0 ASCTy: DAB ] [subch -1 bitrate:0 at SAd:0]
  [0xe0d310bc] TPEG_MM           [component 0 ASCTy: DAB ] [subch -1 bitrate:0 at SAd:0]
  [0xe0d210bc] PPP-RTK-AdV       [component 0 ASCTy: DAB ] [subch 32 bitrate:8 at SAd:468]Attaching RTK Handler to serviceid 3771863228
10

Hier:

11

Respekt! Davon hab’ ich null Ahnung … :open_mouth:

Den Hut ziehend

tracker51

12

Hi,

erst noch einmal vielen Dank für Deinen interessanten Beitrag. Ich finde es durchaus interessant, Korrekturdaten bundesweit ohne Anmeldung, Gebühren und vorhandenes Mobilfunknetz empfangen und nutzen zu können.

Was das Mobilfunknetz betrifft, ist meiner Meinung nach “DAB-RTK” aber trotzdem kein Allheilmittel. Sicher, bei ungestörten GNSS-Empfangsverhältnissen kann es Funklochprobleme verhindern.

Nach meinen Erfahrungen ist mit Funklöchern aber überwiegend in bergiger “Pampa” :wink: zu rechnen, und die sich dort durch ungünstige Geometrie der empfangbaren Satelliten ergebenden Fehler bei der Positionsberechnung können durch die NTRIP-Korrekturdaten wohl eher nicht herausgerechnet werden; dasselbe gilt selbst in Waldgebieten, die in der norddeutschen Tiefebene liegen, besonders bei nassem Laub.

Oder sehe ich da was falsch?

Fragt

tracker51

13

Hi, habt vielen Dank für den vielen Input, sorry ich komme erst jetzt dazu mal zu reagieren …

Naja, ich kann jetzt nur für M-V sprechen, aber klar hast du hier sowohl in der Pampa / Wald Probleme beim Netzempfang, wie auch in den Städten, wenn das Handynetz zu ausgedünnt wurde (siehe 4G Netzabdeckung laut Bundesnetzagentur). Auch hinaus aufs Meer ist das eher übersichtlich …

NTRIP skaliert eben bei der AdV auch nicht besonders gut, wenn zig Rover permanent nach aktualisierten Daten fragen und bedient werden wollen :wink:

Danke mal für deine Beschreibung was man so an Hardware braucht. Ich denke ich werde das Jahr auch mal etwas investieren. Aber vielleicht eher was leichteres so für Drohnen … mal schauen …

Die AdV hat mich mal an die Entwicler weitergeleitet, vielleicht bekommen wir da ja auch etwas Unterstützung. Auf Github wäre ein Amateurfunker aus CH, welcher mit welle.io Analayse sich wohl auch auskennt. Vielleicht macht es Sinn sich gemeinsam drauf zu stüzen? :nerd_face:

14

Nicht nur der RTL-SDR-Stick…

Ich war heute bei schönstem Wanderwetter am Südharzrand in der Gegend um Scharzfeld mit meinem SAPOS-Equipment (s. Post #4) unterwegs. Damit konnte ich angesichts der Empfangsverhältnisse zwar nicht immer die höchsten Positionsgenauigkeiten verzeichnen, aber es gab auch nirgends ein Funkloch!

Wie angekündigt, hatte ich einen kleinen DAB-Empfänger dabei, und zwar dieses Modell. Ich hatte seinerzeit in einem neuen Auto extra den Aufpreis für ein zusätzliches DAB-Empfangsteil bezahlt; leider war es ein paar Jahre später wg. der Umstellung von DAB auf DAB+ völlig nutzlos geworden. So kaufte ich das o.g. Ding als Adapter, um beim Fahren weiter rauschfreie DAB-Sender hören zu können. Das Teil kann aber auch, bestückt mit 2 AA-Zellen, als tragbares DAB-Radio genutzt werden, wobei das Kopfhörerkabel als Antenne dient.

Fazit:

  1. Nach gut zweieinhalb Stunden versagte das Teil seinen Dienst, da nach dieser Zeit die neuen Batterien schon wieder leer waren.
  2. Gewandert bin ich natürlich ohne aufgesetzte Kopfhörer - die hatte ich mir um den Hals gehängt, so dass hauptsächlich und auch nur leise etwas vom Schlagzeug zu hören war.
  3. Während, wie oben gesagt, ständig Mobilfunkempfang gegeben war, war der eingestellte Sender aus dem Bundesmux nur in Ortsnähe ständig zu empfangen. Ob dieses Ergebnis nun realistisch und verallgemeinbar ist, will ich aber nicht entscheiden; vielleicht hat dazu beigetragen, dass ich seinerzeit an dem Adapter eingestellt hatte, dass das Audiosignal bei schlechten Empfangsverhältnissen lieber stummgeschaltet wird, um andernfalls nicht Musik mit Störgeräuschen hören zu müssen.

Soweit diesbezüglich meine 2 Cent …

15

@tracker51 : Danke für die ausführlichen Erläuterungen zu deinem Setup. Mein besonderes Interesse liegt in der genaueren Erfassung der Höhendaten. Da sind die Standard-GPS-Daten zu ungenau und zu verrauscht. Bevor ich mir aber jetzt ein ähnliches System zulege, werde ich es erstmal mit der nachträglichen Korrektur der Höhendaten versuchen. Dafür stehen ja sehr genaue öffentliche Daten zur Verfügung. In NRW zum Beispiel das DGM1 mit einem 1x1 Meter Raster.

16

Hallo Flohoff,

ich habe auch gebastelt. Folgender Code liest den Transparent Data Channel without Data Groups aus dem ISTD aus. datachannel.cpp · GitHub

Ich habe kein Empfang vom Bundesmux, aber kann dessen EDI Zuführung über Satellit bekommen, und das ist ISTD recht einfach rauszurupfen. ISTD ist in EN 300 797 beschrieben. ISTD gibt es Empfängerseitig nicht, und
im welle-io backend ist noch kein Code da, um ein MSC Data Channel zu dekodieren (da ist ein TODO in src/backend/msc-handler.cpp)

Kuck mal, was dab-audio.cpp in process() macht, ich glaube, die Fehlerkorrektur muss auch ein Data Subchannel Dekoder dann machen.

Die Ausgabe von meinem Tool hat GitHub - GeoppGmbH/Geopp-SSRZ-Python-Demo nicht gefressen, aber was nach DAB kommt kenne ich zu wenig.

Gib mir Bescheid, ob du damit weiter kommst.

LG
Matthias

17

Ich würde immer davon ausgehen das ein einfacher DAB+ empfänger VIEL weniger Strom als ein Handy verbraucht. Dein Vergleich ist eher so - mäh. Denn in deinem DAB Radio läuft ein Audio Amplifier die ganze Zeit mit - der verbraucht in dem Konstrukt die meiste Energie.

2xAA Batterie sind sagen wir 2 * 1000mAh * 1.2V = 2.4Wh
Zum Vergleich Pixel 6a 4410mAh bei Vermutlich 3.7V = 16.3Wh

Und auch das mit dem Empfang ist halt eher so Äpfel mit Birnen. Dein kleines Handheld Radio hat eine winzige Antenne am ungünstigen Ort dabei. Aus meiner Erfahrung mit einem DAB Radio im Auto kenne ich das Thema Funkloch nicht mehr. Aktive Antenne auf dem Dach halt. Und wenn du GPS Empfang haben willst brauchst du eh eine Antenna die freie sicht hat. Kleb halt die DAB Antenne daneben.

Ich gehe aktuell davon aus das ganze ein RPi5 + DAB Modul + GPS Modul wird - und dann reden wir vermutlich von 10W die das ganze braucht. Hier braucht der Pi5 die meiste Energie. Schön wäre wenn man das RTK zeugs auf einen esp32 oder ähnliches bringt - das ist aber vermutlich aussichtslos. Das wäre aber meine präferierte methode. Kleine Carrier Platine designen die ein esp32 + X10 + DAB Modul aufnimmt. Dann kommt man vermutlich auf <5W. Wenn man das mit einem SDR macht mit dem DAB Empfang sinds vermutlich 5-8W mehr.

Wenn man von 10W ausgeht muss man halt noch irgendeinen Akku mit einplanen. Wenn es 4h halten soll also 40Wh. Lipos haben 100-150Wh/Kilogramm. Also sinds nochmal 3-500g Akku.

Dazu kommt halt ordentliche Antennen für GPS + DAB, Kabelsalat, etc.
Ich denke das ganze ist dann schon ein bis zwei Kilo die zusammenkommen.

Mir ist das egal - Ich bin aktuell eh mit einem Elektroroller unterwegs und habe 3-4kWh Akku dabei. Und der Akku in der 360° Kamera ist nach einer Stunde auch platt. Nach 2 Stunden ist der interne Speicher voll.
Da ich nur Fotografiere wenn die Sonne über 40° steht d.h. in der Mittagszeit sind das aktuell eh nicht viel mehr Stunden.

Schnell mal das Datenblatt vom Si4684 gesucht - ~45mA bei 1.8V sind 80mW die der DAB+ receiver braucht (Wenn man aus dem denn den Adv RTK stream rausgepopelt bekommt)

Mal sehen - Hardware ist im zulauf …

Flo

1 Like
18

Da bin ich auch drüber gestolpert - Hab mich mal durch die decodierung des MSC und co durchgefräst was die FEC signalisierung angeht. Das sieht alles sauber aus. FEC ist standard standard standard für den Adv RTK PPP stream.

Flo

1 Like
19

Ich hab mal das bisschen was ich bisher zusammen habe gedumped:

Es gibt dann einen neuen command line client “welle-rtk” - Der nimmt einfach den rtl-sdr - tuned auf den Bundesmux auf 5C, sucht sich den PPP-Adv-RTK service und wirft den subchannel in den internen MSC Mux so das callbacks mit den Daten kommen.

Der neue client welle-rtk hat keine abhängigkeiten zu qt6, mpg123, alsa, aac, oder irgendwelchem anderen audio kram. D.h. der client wird kleiner und einfacher zu bauen auf dann RPi5 oder ähnlichem.

Morgen gucke ich mir mal die FEC (Forward Error Correction) für den data packet service an.

Flo

20

Hallo zusammen,

kurz vorweg: Dieser Account ist privat und KEIN offizieller Account des BKG. Es treffen hier zufällig private Interessen und dienstliche Aufgaben aufeinander.
Ich bin in das PPP-RTK-Projekt am BKG involviert und wurde auf den Thread aufmerksam gemacht.
Ich möchte kurz ein paar Worte zur bisherigen Diskussion ergänzen (und vielleicht schon ein paar Fragen beantworten).

Das Echo auf die Vorstellung des neuen PPP-RTK-Satellitenpositionierungsdienstes SAPOS® | GEPOS™ durch Andreas Gerschwitz auf der FOSSGIS-Konferenz vor einigen Tagen ist erfreulich groß.
Der Dienst wird gemeinsam von Bund (Bundesamt für Kartographie und Geodäsie - BKG) und Ländern (Zentrale Stelle SAPOS - ZSS) betrieben und befindet sich seit 1.1.2025 in einer zweijährigen Optimierungsphase.

Das BKG ist Provider des DAB+ - Korrekturdatenstroms.

Derzeit gibt es in verschiedenen Foren Aktivitäten dazu. Wir möchten sehr gern dazu beitragen, Klarheit bzgl. der Fragen zu liefern und ein paar unscharfe Aussagen richtig zu stellen, allerdings können wir dafür nicht mit offiziellem Account in den Foren vor Ort sein. Deshalb:

Zentrale Anlaufstelle für alle Informationen ist die Webseite

https://gepos.sapos.de

wie weiter oben schon richtig erwähnt wurde.
Unter FAQ und Nutzung finden sich alle wesentlichen Informationen zum Dienst und den Verbreitungswegen.

Die FAQs werden mit der Zeit weiter ausgebaut.
Nichtsdestotrotz wirft eine gegebene Antwort oftmals neue Fragen auf.

Aus diesem Grund möchten wir der interessierten openstreetmap-Community ein Online-Meeting anbieten, wo wir Details zum Dienst erklären und auf konkrete Fragen eingehen können.
Sollte dieses Angebot auf Interesse stoßen, würde ich hier um ein kurzes Feedback bitten.

Vielen Dank und viele Grüße
Christoph

5 Likes