Örtlicher Bezugspunkt der parlamentarischen Befassung about spec HOT 17 CLOSED

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?

from spec.

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

from spec.

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.

from spec.

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.

from spec.

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.

from spec.

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.

from spec.

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

from spec.

Workshop 22.01.2014 Bielefeld Gruppe B Vorschlag

siehe dazu #15

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

from spec.

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.

from spec.

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.

from spec.

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

• Bisher gibt es keine Informationen, dass ein existierendes RIS mehr Informationen zur Verfügung stellt.
• Die Standardisierung von Geo-Datenformaten ist weiter in Entwicklung - insbesondere in Zusammenhang mit JSON-LD und auf internationaler Ebene. Dem sollte nicht unnötig vorgegriffen werden.

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

from spec.

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.

from spec.

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.:

• Werden die INSPIRE Spezifikationen Auswirkungen auf RIS haben? Welche?
• Sind eventuell die meisten Punkt-Angaben des RIS in Bonn redundant (=zukünftig überflüssig), weil sie sich aus Strasse und Hausnummer ergeben? ("Hauskoordinaten")
• Was ist bei Verwendung von OpenStreetMap-Daten sinnvoll?

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.

from spec.

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

from spec.

Wird in #103 behandelt.

from spec.

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

from spec.

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

from spec.