LDO - Adressen und Geodaten 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 Prädikat ld:inStreet in ld:inStreetId umbenannt.
• ld:ExterneAdressen -> ld:Adressen
• Ende 2017 wurden die Instanzen von ld:LeipzigerAdressen mit den Prädikaten ld:hasCity und ld:inStreet (in neuer Bedeutung) angereichert.

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 stehen noch nicht zur Verfügung.

Relevante RDF-Graphen

Adressen

• http://leipzig-data.de/RDFData/Adressen.ttl
• http://leipzig-data.de/RDFData/GeoDaten.ttl
• http://leipzig-data.de/RDFData/WeitereAdressen.ttl

Treffpunkte

• http://leipzig-data.de/RDFData/Haltestellen.ttl
• http://leipzig-data.de/RDFData/Spielplaetze.ttl
• http://leipzig-data.de/RDFData/Treffpunkte.ttl

Verwendete Namensräume

• geo: <http://www.w3.org/2003/01/geo/wgs84_pos#>
• geonames: <http://www.geonames.org/ontology#>
• gsp: <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
• gsp:asWKT Literal - Geokoordinaten im WKT-Format, z.B. "Point(12.3902485 51.3210443)"
  • Damit werden Länge und Breite in einem Datenaggregat erfasst. Einer URI können damit mehrere Georeferenzen zugeordnet werden. Das ist insbesondere für die Qualitätssicherung relevant. Die Notation gehört zum GIS-Standard.
  • 2018-02-13: Im Zusammenhang mit der Übernahme von Adressdaten aus "Nachhaltiges Leipzig" wurde das Prädikat in Adressen.ttl übernommen.
• Weitere Prädikate in GeoDaten.ttl - nicht regelmäßig gepflegt
  • geonames:nearbyFeatures URI - Link auf http://linkedgeodata.org/triplify/<OSM-Struktur> - Bezug auf eine OSM-Referenz, deren Geokoordinaten ausgewertet wurden
  • 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 "Dresden, Messering 6"
    • 2018-02-13: Postleitzahl wurde aus dem Label entfernt. Damit einheitliche Darstellung wie Leipziger Adressen.
  • gsp:asWKT Literal - Geokoordinaten im WKT-Format "Point(long lat)"

ld:Treffpunkt - Geolokaler Ort in Leipzig, dem keine Adresse zugeordnet werden kann, in Treffpunkte.ttl, Haltestellen.ttl, Spielplaetze.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"
  • gsp:asWKT Literal - Geokoordinaten im WKT-Format "Point(long lat)"

Änderungen und Historie

• HGG 2018-08-12: Ergänzung weiterer Treffpunkte: Alle Spielplätze (aus codefor.de/leipzig), alle Haltestellen (aus opendata.leipzig.de)
• HGG 2018-02-21: QS der Adressdaten.
• HGG 2018-02-13: Übernahme von Adress- und Geodaten aus "Nachhaltiges Leipzig".
  • Dabei wurde das Prädikat gsp:asWKT in Adressen.ttl übernommen. Weiterhin wurden die Postleitzahlen aus dem Label in WeitereAdressen.ttl entfernt, um eine einheitliche Darstellung mit den Leipziger Adressen zu erreichen.
• 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

Fragen:

• Gibt es eine sinnvolle externe Adress-Ontologie, die übernommen werden sollte? Wie löst das Open Street Map?