search

OParl / spec

Spezifikation für eine offene Schnittstelle für Ratsinformationssysteme
https://oparl.org
Creative Commons Attribution Share Alike 4.0 International
61 stars 21 forks source link

Örtlicher Bezugspunkt der parlamentarischen Befassung #29

Closed dooberlin closed 10 years ago

dooberlin commented 11 years ago

Interessant festzuhalten wäre der Behandlungsgegenstand einer Drucksache sofern sie sich auf einen konkreten Ort/Bezugspunkt bezieht, bspw. im Sinne von einer Abfrage "zeige alle Drucksachen mit Bezug zu "meiner" Straße", zu "meiner" Schule, zu "meinem" Ortsteil, ..."

Hierfür gibt es bereits -sicherlich nicht nur in Berlin- feststehende:

Dazu ein Beispiel aus dem (auch mit Webservice-Schnittstelle ausgestattetem) Regionalen Bezugssystem Berlin (RBS): http://fbinter.stadt-berlin.de/rbs/rbs-slct-str.jsp?beznr=04&otnr=0401&strnr=&strname=Einsteinufer&hausnr=5&go=&mapLabel=&targetUrl=

siehe: http://www.stadtentwicklung.berlin.de/geoinformation/geodateninfrastruktur/de/geodienste/rbs_adressauskunft.shtml

.. könnte das Ganze aber auch etwas überfrachten ..

akuckartz commented 11 years ago

Solange diese Daten nicht explizit erfasst werden können sie nicht über OParl zugänglich gemacht werden. Gibt es RIS-Software die die Erfassung unterstützt?

marians commented 11 years ago

Das Bonner System (BoRis) unterstützt dies. Ein Beispiel: http://www2.bonn.de/bo_ris/ris_sql/sum_dok_info_a.asp?e_caller=fu_geo_ini_positions&e_search_1=92047&e_search_4=1

akuckartz commented 11 years ago

Wenn auch die Hauskoordinaten (also Längen und Breitengrad des Bezugspunktes) in BoRis erfasst sind, dann sollten diese ebenfalls über OParl zugreifbar gemacht werden können.

Eine universelle Behandlung von Adressen, Georeferenzen etc. kann komplex sein. Siehe z.B. http://www.geonames.org/ontology/documentation.html http://www.w3.org/2003/01/geo/ http://www.w3.org/wiki/GeoInfo

Für OParl ist sicherlich eine einfache aber erweiterbare Lösung möglich.

marians commented 11 years ago

Ich sehe hier eine einfache und eine weniger einfache Frage:

  1. Wie sollen beliebig komplexe Geodaten-Geometrien repräsentiert werden? Hierfür schlage ich GeoJSON vor. Damit können einfachste bis komplexe Formen modelliert werden. Das Specs-Dokument enthält bereits Details dazu.
  2. Was bedeuten diese Geodaten? Wird ein Ort-Objekt von einem Drucksache-Objekt referenziert, ist die Frage, was diese Beziehung bedeutet.

Für menschliche Nutzer mag sich diese Bedeutung aus dem Kontext erschließen. Beispiel: Eine Vorlage "Behebung von Straßenschäden an der Hauptstraße 34a" verweist auf ein Ort-Objekt, das die Lage der Hauptstraße 34a beschreibt. Hier ist klar, dass das Ortsobjekt die Lage der geplanten Baumaßnahme bestimmt.

Es sind aber auch komplexere Beispiele denkbar. So könnte es sein, dass sich eine Vorlage mit der Standortwahl für ein neu zu errichtendes städtisches Gebäude beschäftigt. Mit der Vorlage sind mehrere Orte verknüpft. Nutzern könnte nach Einblick in die Drucksache klar werden, welcher Ort was bedeutet. Aber müssen diese Informationen auch maschinenlesbar sein?

Falls jemand hierbei ein Problem sieht, das in Version 1.0 gelöst werden muss, bitte melden und argumentieren. Ansonsten wird die Beziehung zwischen Drucksache und Ort (übrigens eine 1:n Beziehung) ohne weitere semantische Information bleiben.

dooberlin commented 11 years ago

Hallo, wenn mehrere Orte in einer Diskussion sind wie in Deinem Beispiel bezogen auf neue Baumaßnahmen, dann gibt es sachlich noch keinen "Ort" auf den sich die Befassung bezieht, sondern die Befassung bezieht sich auf die "Auswahl", bzw. vor allem auf ein "Gebiet" (neue Schule in einem Schuleinzugsbereich, neuer Spielplatz in einem Ortsteil). Zwischen was genau man wählt, muss nicht auch maschinenlesbar sein, dieser Auswahl-Zustand hat auch meist nur eine geringe Halbwertzeit.

marians commented 11 years ago

Interessante Sichtweise.

Wenn das Grundstück "bei mir gegenüber" als ein möglicher Standort für den Bau eines Hochhauses in Betracht kommt, ist das aus meiner beschränkten Bürgersicht durchaus ein sehr konkreter Ort. Bedenke Anwendungsfälle wie die Benachrichtigungsfunktion über "Dinge, die in meiner Nähe passieren", die ich als sehr relevant einschätze.

Ich denke, dass wir für diesen Anwendungsfall eine ausreichende Modellierungsmöglichkeit zur Verfügung stellen. Die Interpretation, was genau ein Pin auf dem Stadtplan bedeutet, obliegt jedoch dem Endnutzer.

marians commented 10 years ago

Zur Abbildung von Ortsinformationen (Datenmodell) auch noch: http://schema.org/Place (mit GeoCoordinates oder GeoShape im Attribut "geo").

BThie commented 10 years ago

Workshop 22.01.2014 Bielefeld Gruppe B Vorschlag

siehe dazu https://github.com/OParl/specs/issues/15

dies wäre auch dafür eine allgemeingültige Lösung

marians commented 10 years ago

Aktuell gibt es noch keinen offiziellen JSON-LD-context für GeoJSON. Sean Gillies, Entwickler des Python-Tools Fiona, hat jedoch einen definiert. Mehr dazu:

http://sgillies.net/blog/1179/dumpgj-json-ld-and-crs/ http://sgillies.net/blog/2014/01/22/json-ld-and-geojson.html

Ich denke, mit seiner Erlaubnis können wir das übernehmen.

akuckartz commented 10 years ago

Leider sieht Sean Gillies anscheinend mehrere blank nodes sogar im context vor. Das liegt aber vermutlich weniger an ihm als an GeoJSON. Ich halte nach Alternativen Ausschau, die mindestens ebenso ausdrucksstark und kompakt aber Linked Data freundlicher sind.

akuckartz commented 10 years ago

Ich bin inzwischen dafür, für Version 1.0 nur die Koordinaten eines Punktes aufzunehmen. Gründe:

Offen bleibt dann aber noch, ob Angaben zum Koordinatensystem explizit erfolgen müssen oder implizit sind.

marians commented 10 years ago

Zum Koordinatensystem: Hier würde ich gerne den Spielraum einschränken, so dass OParl grundsätzlich WGS84 (EPSG:4326) erwartet.

Die Einschränkung auf Punktdaten wäre, was die aktuelle Praxis betrifft, angemessen. Allerdings muss man dann, sobald ein Systemanbieter etwa Polygone (Grenzen z.B. eines Baugrundstücks) oder LineStrings (Straßenabschnitt) abbilden will, den Standard ändern. Und eine Frage ist auch, ob wir mit einzelnen Features (ein Punkt) auskommen, oder FeatureCollectsion/GeometryCollection (mehrere Punkte) unterstützen müssen. Je größer die GeoJSON-Teilmenge, die wir anbieten wollen, desto weniger sinnvoll wäre eine Beschränkung.

akuckartz commented 10 years ago

Zum Koordinatensystem: Hier würde ich gerne den Spielraum einschränken, so dass OParl grundsätzlich WGS84 (EPSG:4326) erwartet.

Einverstanden. Das wird insbesondere durch http://www.w3.org/2003/01/geo/ erfüllt.

Die Problematik bei Erweiterungen ist klar. Ich habe bei Standards auch gerne eine weitreichende Kompatibilität mit der Zukunft. Aber mir ist hier bisher zu unklar, wie die Zukunft aussehen wird. z.B.:

Aus Linked Data-Sicht ist das übrigens nicht wirklich ein Problem. Wir können bereits für Version 1.0 eine optionale Property namentlich festlegen (oder diese zumindest reservieren), die einen IRI als Wert hat welcher auf ein nicht weiter spezifiziertes Geo-Gebilde verweist.

akuckartz commented 10 years ago

Ich habe eine Wiki-Seite zu INSPIRE und GML angelegt: https://github.com/OParl/specs/wiki/Geo-und-INSPIRE

akuckartz commented 10 years ago

Wird in #103 behandelt.

marians commented 10 years ago

Wenn mich nicht alles täuscht, ist hier nichts mehr offen.

akuckartz commented 10 years ago

Zu INSPIRE habe ich das neue Issue #143 angelegt. Ansonsten ist hier anscheinend alles erledigt.