Zentrale Verwaltung von Netzknoten

Der Netzknotendienst ist ein zentraler Speicher für Netzknoten aller Art. Der Dienst läuft in der cardo Umgebung und stellt alle Methoden als SOAP Service zur Verfügung.

Basis der Umsetzung ist ein Grobkonzept vom 01.09.2017 mit dem Titel "Zentrale Verwaltung von Netzknoten - Entwurfsfassung und Diskussionsgrundlage".

Hintergrund

Eine Registry für Netzknoten kann von verschiedenen Akteuren für den Aufbau eines zusammenhängenden Netzes verwendet werden. Das Netz ist hier nicht näher spezifiziert.

Der Grundgedanke ist, dass ein Knoten ein Abbild eines Gegenstandes der realen Welt darstellt und damit tatsächlich nicht mehrfach auftreten kann und das Änderungen an diesem realen Gegenstand zwangsläufig und tatsächlich alle Nutzer dieses Knotens betreffen muss.

Dabei sind mehrere Aspekte relevant:

• Beim Bearbeiten / Erstellen eines Netzes sollte durch den Ersteller ermittelt werden können, ob an der beabsichtigten Position bereits ein Knoten bekannt ist (innerhalb einer vorzugebenden Toleranz).

• Beim Verschieben / Ändern eines Netzknotens sollen die (anderen) Nutzer die Möglichkeit erhalten über die Änderung informiert zu werden / sich informieren zu können.

• Informationen über die Verwendung des Netzknotens sollten abgerufen werden können (von wem verwendet, wann geändert, etc.).

• Um Konventionen bestehender Systeme gerecht zu werden, sind verschiedene Namen für einen Netzknoten zu berücksichtigen, d.h. es muss eine eineindeutige interne Id (Guid) existieren und alternativ weitere, ebenfalls eindeutige, Alias-Namen.

• Die Belange der realen Welt sind zu berücksichtigen, z. B. das Knoten aus 2D Sicht übereinander liegen können (Brücken, Unterführungen).

• Für zukünftige Erweiterungen sollten weitere Metadaten zu einem Knoten angegeben werden können.

Konzepte

"Benutzer"

Intern wird mit einem Benutzerobjekt gearbeitet, welches logisch als Konstrukt aus Organisation & Anwendungsdomäne aufgefasst wird. Es handelt sich dabei demzufolge nicht um eine Einzelperson.

Ein Nutzer in diesem Sinne wäre bspw. "Anwendung Wegekataster des Landkreises XXX".

Da es sich um eine Server<->Server Kommunikation handelt, ist dies auch nicht mit Nachteilen in der Anwendung verbunden, spart aber Verwaltungsaufwand aufseiten des Dienstes, bspw. was die Zuordnung Nutzer -> Organisation betrifft.

Der Dienst stellt einige Methoden bereit, die in diesem Nutzerkontext laufen. Bspw.:

• RegisterNodeUsage
• ReportChangesOnMyUsedNode
• UpdatePersonalData

Technisch betrachtet erfolgt der Zugriff immer unter Anmeldung mit einer cardo Kennung. Die cardo Nutzer müssen das Start-Recht für die Anwendung haben.

Datenmodell

Netzknoten bestehen aus der

• Lage, d.H. Ost (x), Nord (y) und Bezugssystem (epsgCode),
• einer internen eindeutigen Id (Basis ist eine Guid, aber sicher in der Verwendung als XmlId),
• einer Qualitätsangabe
• und aus Metadaten zu Ersteller/Erstellt/Ändernder/Geändert.

Das Raumbezugssystem ist dabei eine Anwendungseinstellung, alle Netzknoten werden in der gleichen Projektion gespeichert und bei Bedarf in das Zielsystem umgerechnet.

Änderungen an der Lage werden über eine Generation (Zahlenwert, Startwert ist 1) berichtet.

Jede signifikante Änderung an der Lage führt zum Erhöhen der Generation. Die Lagen der älteren Generationen werden jeweils archiviert.

Benamung / Identifikation

Zur Kommunikation mit Drittsystemen können weitere Ids zu einem Netzknoten erstellt werden. Dazu gibt es das Konzept der Namingprovider.

Die Namingprovider werden über ein Kürzel (Prefix) angesprochen. Ein solcher Provider kann für eine automatische ID Vergabe verwendet werden.

Die zusätzlichen Ids eines Netzknotens müssen dabei pro Namingprovider eindeutig sein.

Es gibt drei Ausprägungen der Namingprovider:

• Build-In: Eingebaute Provider, die auch für die automatische Namensvergabe verwendet werden können.

  z.Z. "TK25" => ermittelt die TK25 Blattnummer, dann den höchsten Wert der Id, der bereits in dem TK Blatt vergeben wurden. Der Ergebnisbezeichner ist immer AAAAnnnn (4 Stellen Blattnummer, 4(!) Stellen laufende Nummer, mit 0 gefüllt).

  Build-In Provider müssen programmtechnisch implementiert werden.

• Generisch: Von diesem Provider können beliebig viele Instanzen unter einem zu vergebenden Prefix registriert werden, eine automatische Nummernvergabe ist nicht möglich.

• "$Me": Ein Provider, der abhängig vom Nutzer automatisch registriert wird, eine automatische Nummernvergabe ist nicht möglich.

Die Verwendung der Präfixe ist nie case-sensitiv, d.h. Groß/Kleinschreibung wird nicht beachtet.

Ansprache von Knoten über den nodeIdentificator

In den Methoden wo als Parameter ein nodeIdentificator erwartet wird, sind folgende Formate möglich:

• "InterneId": (Bspw..: "cc0af026-b30b-476e-93a3-da8b12f5245a")
• "Prefix:Id": (Bspw.: LiST.NKN:5150017O) Hier wird der Knoten angesprochen, der in dem Naming-Provider "LiST.NKN" die Id 5150017O hat.

Der Doppelpunkt trennt dabei den Namingprovider Prefix und den Id-Wert.

In der Id darf selber auch ein Doppelpunkt vorkommen, bei den internen Ids tritt dies nie auf.

Erstellen von Netzknoten

Das Erstellen der Netzknoten erfolgt durch Aufruf der entsprechenden Methoden, dabei wir die Lage und ggf. ein nodeIdentificator mit übergeben.

Netzknoten können auch doppelt an der gleichen Lage erstellt werden. Optional kann das System angewiesen werden, bei Doppelungen einen Fehler auszulösen.

Die Lage und Ids vorhandener Netzknoten können später jederzeit geändert werden.

Z.Z. gibt es keine Sicherheitseinschränkungen wer Änderungen durchführen darf. Technisch wären verschiedene Möglichkeiten denkbar, bspw. nur dem Ersteller Änderungen zu erlauben.

Verwendung von Netzknoten

Wenn ein Nutzer einen der Netzknoten in seinem System verwendet, dann registriert er diese Verwendung im Netzknotendienst. Dabei wird der Zeitpunkt und die Generation des Netzknotens zum Zeitpunkt der Zuweisung gemerkt.

Mit diesen Information kann der Dienst den Nutzer über signifikante Änderungen informieren, bzw. der Nutzer kann jederzeit die Liste geänderter, für ihn relevanter, Knoten abrufen.

Wird der Knoten nicht mehr benutzt, kann die Information durch unregistrieren wieder entfernt werden.

Knoten die von mindestens einem Benutzer verwendet werden, können nicht gelöscht werden.

Abrufen von Netzknoten

Für den Abruf von Netzknoten gibt es drei Methoden:

• Einzelobjekt, anhand eines nodeIdentificator,
• Alle Netzknoten an einem Punkt innerhalb eines Radius,
• Alle vom Aufrufer verwendeten und zwischenzeitlich geänderten Netzknoten,
• Alle Netzknoten (optional mit Offset/Limit)

---

Anhang - Dokumentierte Datenstrukturen

Die Typen entsprechen den Rückgabewerten der Dienstemethoden.

Die Liste ist nur ein Auszug der relevanten Datentypen, in den Kommentaren ist die Bedeutung der Datenfelder zu entnehmen.

---

Enumerationstypen

/// <summary>
/// Genauigkeitsangaben
/// </summary>
public enum AccuracyType
{
	/// <summary>
	/// Geschätzt, frei digitalisiert
	/// </summary>
	Estimated = 0,
	/// <summary>
	/// Eingemessen
	/// </summary>
	Measured = 1000
}

Allgemeine Rückgabe einiger Methoden:

/// <summary>
/// Ergebnis einer Aktion
/// </summary>
public enum ActionResult
{
	/// <summary>
	/// Keine Änderung erfolgt.
	/// </summary>
	Nothing,
	/// <summary>
	/// Eine Aktualisierung wurde durchgeführt.
	/// </summary>
	Updated,
	/// <summary>
	/// Ein Datensatz wurde neu erstellt.
	/// </summary>
	Inserted,
	/// <summary>
	/// Ein Datensatz wurde gelöscht
	/// </summary>
	Deleted
}

---

Netzknoten, Basistyp

Methoden: GetAllNodes ,TryGetNodeById , ...

class Node
{
	/// <summary>
	/// Die eindeutige Id des Knotens
	/// </summary>
	[System.Xml.Serialization.XmlAttribute("id")]
	public string UniqueId { get; set; }
	/// <summary>
	/// Ostwert
	/// </summary>
	[System.Xml.Serialization.XmlAttribute("x")]
	public double X { get; set; }
	/// <summary>
	/// Nordwert
	/// </summary>
	[System.Xml.Serialization.XmlAttribute("y")]
	public double Y { get; set; }
	/// <summary>
	/// Epsg-Code
	/// </summary>
	[System.Xml.Serialization.XmlAttribute("epsg")]
	public int EpsgCode { get; set; }
	/// <summary>
	/// Zeitpunkt der Erstellung
	/// </summary>
	[System.Xml.Serialization.XmlAttribute("created")]
	public DateTime Created { get; set; }
	/// <summary>
	/// Zeitpunkt der letzten Änderung
	/// </summary>
	[System.Xml.Serialization.XmlAttribute("modified")]
	public DateTime Modified { get; set; }
	/// <summary>
	/// Generation (Änderung), Startwert ist 1
	/// </summary>
	[System.Xml.Serialization.XmlAttribute("gen")]
	public int Generation { get; set; }

	/// <summary>
	/// Genauigkeit
	/// </summary>
	[System.Xml.Serialization.XmlAttribute("accuracy")]
	public AccuracyType Accuracy { get; set; }
}

---

Netzknoten mit Änderungen eines in Verwendung registrierten Knotens für den aktuellen Nutzer.

Methoden: ReportChangesOnMyUsedNode

/// <summary>
/// Änderungen an "Meinen" Nodes
/// </summary>
public class NodeChanges
{
	/// <summary>
	/// Abstand letzte Aktualisierung / aktueller Node in Metern
	/// </summary>
	[System.Xml.Serialization.XmlElement("Distance")]
	public double Distance { get; set; }
	/// <summary>
	/// Zeitpunkt der letzten Zuweisung
	/// </summary>
	[System.Xml.Serialization.XmlElement("AssignedAt")]
	public DateTime Assigned { get; set; }
	/// <summary>
	/// der neue Knoten
	/// </summary>
	[System.Xml.Serialization.XmlElement("CurrentNode")]
	public Node Node { get; set;}	
}