Skip to content

[Epic] Routing mit Auflösung Adresse zu ARS

Pitch

Outcome:

Auf welches strategische Ziel zahlt das Feature ein? Was ändert sich, wenn das Feature verfügbar ist?

  • Weiterentwicklung Routing

Zielgruppe:

Wer profitiert von diesem Feature?

  • Onlinedienste bzw. Onlinediensthersteller

Opportunity:

Welches Problem lösen wir bei unserer Zielgruppe?

  • Entscheidend für die Zuständigkeit ist meist der Wohnort des Antragstellers oder der Sitz eines Unternehmens oder sonst eine angegebene Adresse (z.B. Ort eines Bauvorhabens).
  • Die Zuständigkeit wird jedoch vornehmlich über den ARS festgelegt.
  • Jeder Onlinedienst muss es also schaffen, eine Adresse zu einem ARS aufzulösen. Die RTD-API bietet mit dem Area-Endpunkt zwar die Möglichkeit, mit Name oder PLZ nach einem Gebiet zu suchen, das dann für die Zuständigkeitsklärung alternativ zum ARS verwendet werden kann, eine Adresse wäre jedoch feingranularer und gerade bei ARS auf der Ebene von Stadtbezirken von Bedeutung. Bei Stadbezirken kann es nämlich vorkommen, dass die Trennung zwischen zwei Bezirken innerhalb einer Straße verläuft.

Kurzbeschreibung:

Was ist sonst noch wichtig zu wissen?

  • RTD ermöglicht es bei GET /routes alternativ zu ARS / AGS / AreaID eine Adresse anzugeben.
  • RTD löst die Adresse mittels HK-DE zu Geokoordinate auf.
  • RTD löst Geokoordinate mittels WFS (https://gdz.bkg.bund.de/index.php/default/wfs-verwaltungsgebiete-1-250-000-stand-01-01-wfs-vg250.html) zu ARS auf. Es wird immer der ARS der niedrigsten Verwaltungsebene (Kommune) ermittelt, da die bisherige Zuständigkeitsklärung mit ARS bereits hierarchisch funktioniert.
  • RTD ermittelt Route in PVOG / Linie6Plus / ZSD wie bisher mit Leistung und dem ermittelten ARS.

Entscheidungen:

Gibt es Entscheidungen, die jetzt schon getroffen werden sollten? Sind Beschaffungen notwendig?

  • In welchem Format wird die Adresse ind der Routing-API als Parameter übergeben?
  • Wie wird der Fall behandelt, dass die übergebene Adresse zu keiner eindeutigen Koordinate führt, z.B. wenn die Angaben zu mehreren Adressen passen?

(Externe) Deadline:

Gibt es externe Deadlines die berücksichtigt werden müssen?

Prioritätsbewertung:

Wie gewichten wir die RICE Faktoren auf einer Skala von 1 bis 10?

  • Reach:
  • Impact:
  • Effort:
  • Confidence:
  • RICE-Gesamtscore:

Vorbereitung Epic Refinement

  • Wer kümmert sich darum, dass ein Epic "refinement ready" gemacht wird? @Andreas_Aschauer
  • Welche Teams werden perspektivisch am Feature arbeiten? Welche Devs aus den Teams sollten jetzt schon eingebunden werden? teamRTD
  • Bei welchem Epic Refinement kann dieses Feature voraussichtlich besprochen werden? Direkt mit teamRTD

Persona

Karl Urban, PO eines Onlinediensts:

User Story: Als PO möchte er in seinem Onlinedienst das Routing in einer einheitlichen, auch komliziertere Fälle abdeckenden Variante umsetzen.

Jobs

  • Optimierung des Antragsrouting seitens des Onlinediensts

Pains

  • Der Onlinedienst konnte bisher nur mit Ort / PLZ Routen ermitteln.
  • Für komplizierte Zuständigkeiten mussten Workarounds genutzt werden.

Gains

  • Ein Routing anhand der kompletten Adresse deckt den Großteil der Anwendungsfällte mit einer einheitlichen Lösung ab.

Epic Ausarbeitung

Warum

Das Kriterium für die Ermittlung der regionalen Zuständigkeit ist in der Regel eine Adresse, z.B. der Wohnort einer natürlichen Person, der Sitz einer juristischen Person oder die Adresse eines Bauvorhabens. Meist reicht der Ort zur Bestimmung der Zuständikeit, es kann jedoch vorkommen, dass die Grenze von Zuständigkeitsgebieten innerhalb einer Straße verläuft. Besonders dann wird es für Onlinedienste leichter, mit der gesamten Adresse nach der Zuständigkeit zu suchen.

Ziel

Onlinedienste rufen den Routingdienst mit der Angabe einer Leistungskennung und einer Adresse auf und erhalten die passende Route.

  • RTD ermöglicht es bei GET /routes alternativ zu ARS / AGS / AreaID eine Adresse anzugeben.
  • RTD löst die Adresse mittels HK-DE zu Geokoordinate auf.
  • RTD löst Geokoordinate mittels WFS (https://gdz.bkg.bund.de/index.php/default/wfs-verwaltungsgebiete-1-250-000-stand-01-01-wfs-vg250.html) zu ARS auf. Es wird immer der ARS der niedrigsten Verwaltungsebene (Kommune) ermittelt, da die bisherige Zuständigkeitsklärung mit ARS bereits hierarchisch funktioniert.
  • RTD ermittelt Route in PVOG / Linie6Plus / ZSD wie bisher mit Leistung und dem ermittelten ARS.

Links, Hinweise, Bemerkungen

Stories

Akzeptanzkriterien

  1. Bei GET /routes kann alternativ zu ARS / AGS / AreaID eine Adresse angegeben werden.
  2. Wurde eine Adresse angegeben ermittelt RTD mithilfe der HK-DE-Daten deren Koordinate.
  3. Mit der Koordinate ermittelt RTD anhand des WFS Verwaltungsgebiete den ARS der niedrigsten Verwaltungsebene.
  4. Mit der Leistungskennung und dem ermittelten ARS wird die Ermittlung der Route wie bisher fortgeführt.
  5. ? Wird mit der angegebenen Adresse in den HK-DE-Daten mehr als ein Match gefunden, werden alle Treffer (Adressen) zurückgegeben, damit der Onlinedienst den Nutzer auswählen lassen und dann den RTD mit der konkreten Adresse erneut aufrufen kann. ?
  6. Die neue Funktion ist iner der RTD-API und der Dokumentation beschreiben, insbes. der Umgang mit AK5.
  7. Definition of Done wurde überprüft.

Mögliche Folgeaktivitäten

Offene Fragen

  • Adressformat
  • Verhalten bei ambivalenten Adress-Angaben
  • Integration HK-DE (Daten im RTD oder Abruf per API)
Edited by Andreas Aschauer