Adressen der Stadt Leipzig

Allgemeines

Eine Adresse ist ein geolokaler Punkt in der Stadt Leipzig mit einer Hausnummer, wo zum Beispiel eine Postzustellung möglich ist. Die Daten (über 65.000 Datensätze) wurden im Rahmen des API-Leipzig Projekts von der Stadtverwaltung (einschließlich Referenzen auf das Straßenverzeichnis) übernommen, im Rahmen des Leipzig Data Projekts in das RDF-Format transformiert und in Adressen.ttl zusammengefasst.

Hausnummern sind Grundstücken zugewiesen, diese können aus mehreren Flurstücken bestehen. Verschiedene Gebäude auf einem solchen Grundstück könnten später durch URIs bezeichnet werden, die die Grundstücksadresse als Namenspräfix haben. Damit folgt unsere Bezeichnung der im Kataster.

Im Rahmen des Linked Geodata Projekts wurden diese Daten mit Geodaten angereichert. Die Daten wurden initial von Claus Stadler über nominatim aus Open Streetmap extrahiert, danach weiter ergänzt und aktualisiert.

Ausgewählte Adressen außerhalb von Leipzig sind in WeitereAdressen.ttl nach demselben URI-Schema in einer verkürzten Ontologie erfasst.

Es gibt geolokale Punkte, die nicht durch eine solche Adresse referenziert werden können, wie Treffpunkte, Kinderspielplätze u.ä. Dafür wurde das Konzept Treffpunkt eingeführt, das aus einem Bezeichner und weiterer geolokaler Information besteht.

In Anwendungen (etwa den Events) sind die standardisierten Adressen bis auf die Hausnummer aufgelöst. Weitere Informationen sind als Adresszusatz (ld:hasAddressAddendum) einzutragen.

Im Zuge der weiteren Standardisierung wurde am 12.11.2017 die Klassen umbenannt

  • ld:Adressen -> ld:LeipzigerAdressen (konzeptionell rdfs:subClassOf ld:Adressen) und dabei das Prodikat ld:inStreet in ld:inStreetId umbenannt.
  • ld:ExterneAdressen -> ld:Adressen
  • ld:LeipzigerAdressen ist noch anzureichern mit den Prädikaten ld:hasCity und ld:inStreet (in neuer Bedeutung)

Es gibt weiter ein Liegenschaftskataster der Stadt Leipzig mit den Begriffen Gemarkung (nicht ganz deckungsgleich mit den Ortsteilen), Flurstück und Grundstück. Diese Informationen stehn noch nicht zur Verfügung.

 

Relevante RDF-Graphen

Verwendete Namensräume

  • geo: <http://www.w3.org/2003/01/geo/wgs84_pos#>
  • geonames: <http://www.geonames.org/ontology#>
  • geosparql: <http://www.opengis.net/ont/geosparql#>
  • ld: <http://leipzig-data.de/Data/Model/>
  • rdfs: <http://www.w3.org/2000/01/rdf-schema#>

Klassen

  • ld:LeipzigerAdresse – Adresse in der Stadt Leipzig in Adressen.ttl und Georeferenzen in GeoDaten.ttl
    • konzeptionell rdfs:subClassOf ld:Adressen
  • ld:Adresse – Ausgewählte Adressen außerhalb der Stadt Leipzig in WeitereAdressen.ttl
  • ld:Treffpunkt – Geolokaler Ort in Leipzig, dem keine Adresse zugeordnet werden kann, etwa Spielplätze. Siehe Treffpunkte.ttl

Beschreibung der Prädikate

ld:LeipzigerAdresse – Adresse in der Stadt Leipzig

  • URI-Struktur http://leipzig-data.de/Data/<plz>.Leipzig.<Straßenname>.<Hausnummer>
  • rdfs:subClassOf ld:Adressen
  • Weitere RDF-Prädikate in LeipzigerAdressen.ttl
    • ld:inOrtsteil ld:Ortsteil – Ortsteil, in welchem sich die Adresse befindet
    • ld:inStreetId ld:Strasse – Straße, in welcher sich die Adresse befindet
  • Georeferenzen in GeoDaten.ttl
    • geonames:nearbyFeatures URI – Link auf http://linkedgeodata.org/triplify/<OSM-Struktur> – Bezug auf eine OSM-Referenz, deren Geokoordinaten ausgewertet wurden
    • geosparql:asWKT Literal – Geokoordinaten im WKT-Format, z.B. “Point(12.3902485 51.3210443)”
      • Damit werden Länge und Breite in einem Datenaggregat erfasst, womit einer URI mehrere Georeferenzen zugeordnet werden können. Das ist insbesondere für die Qualitätssicherung relevant.
      • Ohne diese Tupel-Bildung ist nicht klar, welche lat-long zusammengehören.
      • Notation gehört zum GIS-Standard.
    • geo:lat float – geografische Breite
    • geo:long folat – geografische Länge

ld:Adresse – Ausgewählte Adressen außerhalb der Stadt Leipzig in WeitereAdressen.ttl

  • URI-Struktur http://leipzig-data.de/Data/<plz>.<Ort>.<Straßenname>.<Hausnummer>
  • RDF-Prädikate
    • ld:hasPostCode Literal – Postleitzahl
    • ld:hasCity Literal – Stadt
    • ld:hasStreet Literal – Straße, in welcher sich die Adresse befindet
    • rdfs:label Literal – Bezeichner, etwa “01067 Dresden, Messering 6”

ld:Treffpunkt – Geolokaler Ort in Leipzig, dem keine Adresse zugeordnet werden kann, in Treffpunkte.ttl

  • URI-Struktur http://leipzig-data.de/Data/Treffpunkt/<Bezeichner>
  • RDF-Prädikate
    • rdfs:label Literal – Bezeichner, etwa “Elsterbecken, Landauer Brücke, Hans-Driesch-Straße”
    • geosparql:asWKT Literal – Geokoordinaten im WKT-Format “Point(long lat)”
    • geo:lat float – geografische Breite
    • geo:long folat – geografische Länge

Änderungen und Historie

  • HGG 2017-12-13: ld:hasCity und ld:inStreet in ld:LeipzigerAdresse ergänzt
  • Frage: Können Geokoordinaten aus ld:hasCity, ld:hasPostCode, rdfs:label inferiert werden
  • HGG 2017-11-12: Umbenennung der Klassen in ld:LeipzigerAdresse und ld:Adresse zur Konsolidierung des Modells
  • HGG 2015-02-09: Zuordnung zu Ortsteilen aus API-Leipzig erneut und diesmal korrekt übernommen.
  • HGG 2014-04: Hausnummern wie “10-11” werden grundsätzlich auf die URI mit der kleinsten Hausnummer aus diesem Intervall gemapt, die im Adressverzeichnis der Stadt angegeben ist, um die Anzahl der URIs nicht zu sehr aufzublähen.
  • HGG 2013-10-20: URIs nach einheitlichem neuen Konzept umgesetzt
  • HGG 2013-03-10: Externe Adressen sind in WeitereAdressen.ttl ausgelagert und gehören nun zu einer eigenen Klasse ld:ExterneAdresse.

Fragen:

  • Gibt es eine sinnvolle externe Adress-Ontologie, die übernommen werden sollte? Wie löst das Open Street Map?
  • Straßen als Objekte außerhalb von Leipzig werden nicht eingeführt, im rdfs:label Straße und Hausnummer gemeinsam.