Augsburg/Datenspende Stadtplan für barrierefreie Mobilität

Die Erst-Erstellung dieser Seite erfolgt durch --Okilimu 19:50, 25 June 2010 (UTC)

please change curb to kerb

and remove this afterwards. Curb is American English, we agreed to use British English for ease of editing (not having to wonder which way it is).

Aktueller Stand

05.08.2010:

• Import und Integration der Daten innerhalb Testgebiet abgeschlossen (am 5.8.2010).

• Im nächsten Schritt sind die Daten zu präsentieren vor den Datenherren (Stadt Augsburg und Uni Augsburg).

Stand: 07/2010: Testgebiet definiert: in diesem werden die Daten aktuell importiert (15% aller Objekte sind im Testumfang).

Beschreibung der Daten

Die Daten des Stadtplan für barrierefreie Mobilität der Stadt Augsburg dürfen mit Genehmigung der Stadt Augsburg (beteiligtes Stadtvermessungsamt und Sozialreferat) sowie der Universtität Augsburg, Lehrstuhl für Humangeographie und Geoinformatik, die die Erfassung durchgeführt hat, in openstreetmap unter der Lizenz CC-BY-SA 2.0 verwendet werden.

Übernahmeregelung

Am 18.06.2010 teilte der Lehrstuhl der Universität mit, daß die gesamten Daten in openstreetmap übernommen werden können. In einer ersten Stufe soll die Übernahme in einem Teilgebiet durchgeführt werden.

Am 25.06.2010 wurde das Teilgebiet definiert und hierfür nochmal eine explizite Genehmigung zur Verwendung in openstreetmap unter der CC-BY-SA 2.0 Lizenz bestätigt.

Datenkonvertierung

Die Daten werden beim Lehrstuhl der Universität in einem W3GIS System erfasst und gespeichert, die Sachdaten liegen in einer angebundenen Microsoft Access Datenbank vor.

Zur Übernahme der Geometriedaten wurde die darauf aufbauende Anwendung SchulGIS verwendet.

Der Lehrstuhl der Universität erstellte für schulische Belange eine Schnittstelle von und nach openstreetmap.

Da nur ein Teil der clientseitigen W3GIS API-Schnittstelle offen lag, wurden die Sachdaten aus der MS Access Datenbank exportiert und Transformationsregeln je Datentyp definiert.

Mit einer kleinen Erweiterung der Export-Schnittstelle konnten so die Geometriedaten (mit einer Transformation von GK4 nach WGS84) und die Sachdaten zusammen in einzelne OSM-Dateien rausgeschrieben werden (je GIS-Layer eine OSM-Datei).

Datenstruktur und Transformation nach osm

Allgemeines

Im folgenden werden Sachdaten, die nicht sauber in vorhandene OSM-Tags übernommen werden können, mit einem Key-Prefix "augsburgbarrierefrei" versehen, gefolgt von ":" und einem Sub-Key.

Diese OSM-Tags werden im Rahmen des Imports oder danach in die korrekten OSM-Tags umgewandelt und diese proprietären Keys dann entfernt.

Der Sachdaten-Tabellenname wird mit "augsburgbarrierefrei:tabelle" und die IDs jedes Sachdatensatzes mit "augsburgbarrierefrei:ref" getaggt und helfen beim Import bei auftretenden Problemen. Diese werden ebenfalls später entfernt.

Absenkung

Verlauf einer Bordsteinkante mit Angabe der Kantenhöhe und Kanteneigung.

• Die Bordsteinkante kommt in der Länge vor, bei der die Höhe konstant war.

• Die Bereiche, an dem der Bordstein nicht abgesenkt ist, liegt normalerweise nicht als Geometrie vor.

• Der eigentliche Fußweg liegt normalerweise NICHT als Geometrie vor. Der Fußweg liegt dann teilweise oder komplett als Geometrie (dann als Fläche, technisch geschlossener Weg) vor, wenn der Belag erfasst wurde und/oder eine Längs- oder Querneigung des Fußweges vorhanden ist (siehe entsprechende Datenstrukturen).

Die Bordsteinkanten geometrisch offene Wege.

Beginn Neuigkeit 6.7.2010

Veraltet: (HINWEIS: Für eine Bordsteinkante an sich gibt es aktuell in 06/2010 kein OSM-Tagging. Diese Datenstruktur wird vorerst nur zur Unterstützung bei der Korrektur vorhandener Daten verwendet, aber noch nicht importiert.)

Aktuell (6.7.2010): Es wird das neue Tagging barrier=curb eigenhändig eingeführt, zusätzlich die Höhe der Kante mit height=* in x.x(x) in [m].

Dieses neue Tagging wurde am 6.7. auf der Seite Proposed features/New barrier types ergänzt, weitere Details auf der talk-Seite dazu.

Diese neue Vorgehensweise wird nach der Produktivkonvertierung im osm-File nachgezogen.

Ende Neuigkeit 6.7.2010

Die im folgenden genannten OSM-Tags sind daher noch nicht vollständig und werden möglicherweise noch geändert.

Allgemeine Vorhensweise bei Integration in openstreetmap: wenn der Absenkungs-Weg als längeres Stück vorhanden ist und die Breite des Fußwegs bekannt ist, wird der Abschnitt genommen, um eine flächenhafte Darstellung des Fußwegs zu erstellen. Der Kantenverlauf wird auf der anderen Seite des Weges parallel verwendet, außerdem in Fußweg-Mitte der Fläche als Fußweg-Weg, an dem die Absenkungsdaten mit sloped_curb:left=* oder sloped_curb:right=* gesetzt wird. Der Anstieg wird mit incline:left=* oder incline:right=* getaggt (beim Anstieg ist die entgegengesetzte Richtung zur Angabe der Neigungsrichtung im GIS-System zu beachten).

Bei der Fläche wird nur die Neigung getaggt, mit incline=* und incline:direction=*, siehe dazu Augsburg/Datenspende Stadtplan für barrierefreie Mobilität#incline erweitern auf Fläche incline erweitern auf Fläche.

Feldname	Feldtyp	osm-Tagging	Bemerkungen
AbsenkungID	ID	augsburgbarrierefrei:tabelle=Absenkung vorübergehend augsburgbarrierefrei:ref=* vorübergehend
Kante	numerisch Double (tatsächlich inkl. optional einstellige Nachkommastelle)	sloped_curb=* im Format x.x(xx), Einheit in [m]	Falls später als Bestandteil eines Fußwegs, dann so übernehmen, da beim Fußweg pur sloped_curb verwendet wird, also Suffixe :left und :right entfallen.
Neigung	numerisch Integer	???	OFFEN: noch unklar, welche Einheit und Aussage dieses Feld hat. Wird geklärt.
Problem	boolean	FIXME=Problem ohne weitere Angaben, siehe ggfs. vorhandene zusätzlichen Key note
Vermerk	text	note:de=*

Ampel

Beschreibung einer einzelnen Fußgängerampel an einer Überquerung. Die Ampel liegt als Knoten mit der Koordinate vor, wo sie in der Natur steht (in openstreetmap andere Vorgabe für Erfassungsort !). Jede Ampel hat einen entsprechenden Sachdatensatz.

Darüber hinaus liegen noch offene Wege ohne Sachdatensatz vor, die die linke und rechte Markierung des Überquerungsweges je Fahrrichtung begrenzen. Die vorliegenden puren Geometrien für die linken und rechten Begrenzungen des Überquerungsweges könnten bzgl. Abstand voneinander vermessen werden und dann als width=* im Format x.x(x) mit Einheit [m] beim Überquerungs-Fußweg getaggt werden.

Außerdem liegen Zebrastreifen mit den einzelnen Streifen vor, auch hier fehlt ein Sachdatensatz dazu. Die Zebrastreifenübergänge sind auch nicht in Form einer einzelnen Koordinate hier oder in einer anderen Datenstruktur definiert, müssen also händisch nacherfasst werden.

Feldname	Feldtyp	osm-Tagging	Bemerkungen
		highway=crossing	Hinweis: dieses Tagging ist nur zur Speicherung der Sachdaten gedacht. Beim Import in osm wird das Tagging geändert in: barrier=traffic_crossing_pole für den Ampelmast-Standort. Die Keys/Values sind zum händisch zu ergänzenden Überquerungsknoten zu transferieren. Nur die folgenden Daten verbleiben parallel auch am Ampelmast-Standort: tactile_paving=*
AmpelID	ID	augsburgbarrierefrei:tabelle=Ampel vorübergehend augsburgbarrierefrei:ref=* vorübergehend
Ampeltyp	2|3	1 (= normal) crossing=traffic_signals crossing_ref=pelican 2 (= Drücker) crossing=traffic_signals crossing_ref=toucan 3 (= nur Blinksignal) note:de=nur blinkend
Signaltyp	2|3|4	1 (=ohne) traffic_signals:vibration=no traffic_signals:sound=no 2 (=aktustisch) traffic_signals:vibration=no traffic_signals:sound=yes 3 (=taktil) traffic_signals:vibration=yes traffic_signals:sound=no 4 (=akustisch und taktil) traffic_signals:vibration=yes traffic_signals:sound=yes
Problem	boolean	FIXME=Problem ohne weitere Angaben, siehe ggfs. vorhandene zusätzlichen Key note
Vermerk	text	note:de=*	Hier kommen Hinweise zu defekt oder "haptisch" oder CHECK-Hinweise vor

Belag

Fußweg-Fläche auf normalem Fußweg oder in Fußgängerzone, bei dem ein Belag in gleichbleibendem Zustand vorliegt.

Feldname	Feldtyp	osm-Tagging	Bemerkungen
		area=yes highway=pedestrian	highway=pedestrian wird gesetzt, weil meistens in Fußgängerzone. Muß beim Import ggfs. angepasst werden in highway=footway oder highway=living_street
BelagID	ID	augsburgbarrierefrei:tabelle=Belag vorübergehend augsburgbarrierefrei:ref=* vorübergehend
Art	numerisch 1..8	1 (= Asphalt/Beton) surface=asphalt FIXME=* 2 (= Betonplatten) surface=paving_stones 3 (= Natursteinplatten) surface=paving_stones augsburgbarrierefrei:surface=Natursteinplatten) 4 (= Kopfsteinpflaster) surface=cobblestone 5 (= Natursteinpflaster) surface=cobblestone augsburgbarrierefrei:surface=Natursteinpflaster) 6 (= Betonpflaster) surface=cobblestone 7 (= Schotter/Kies) surface=pebblestone FIXME=* 8 (= Erde) surface=groud	OFFEN: Die Definitionen und Interpretationen bei der Erfassung sind nochmal nachzufragen
Zustand	2|3	1 (=gut) smoothness=good 2 (=ausreichend) smoothness=intermediate 3 (=schlecht) smoothness=bad	OFFEN: Die Definitionen und Interpretationen bei der Erfassung sind nochmal nachzufragen
Problem	boolean	FIXME=Problem ohne weitere Angaben, siehe ggfs. vorhandene zusätzlichen Key note
Vermerk	text	note:de=*

Einrichtung

Städtische Ämter, Touristenattraktionen und weitere Einrichtungen liegen als Punkte vor, inkl. einiger Sachdatenfelder.

Andere Datenstrukturen für die Gebäudezugänge (alle mit Prefix Zugang) beziehen sich auf diese Punktobjekte.

Feldname	Feldtyp	osm-Tagging	Bemerkungen
EinrichtungID	ID	augsburgbarrierefrei:tabelle=Einrichtung vorübergehend augsburgbarrierefrei:ref=* vorübergehend
Name	text	name=*
Typ	2|3|4	1 (=Amt) amenity=public_building 2 (=Sehenswürdigkeit) tourism=attraction 3 (=sonstige Einrichtung) amenity=yes FIXME=Einrichtungsart definieren 4 (=Touristeninformation) tourism=information
Adresse	text	-	Hinweis: Feld wurde in die zwei Felder AdressStrasse und AdressHausnr gesplittet und die Adressteile passend getrennt, siehe nachfolgende Beschreibungen dazu
AdressStrasse	text	addr:street=*	Hinweis: Feld wurde ergänzt, siehe Hinweis bei Originalfeld Adresse
AdressHausnr	text	addr:housenumber=*	Hinweis: Feld wurde ergänzt, siehe Hinweis bei Originalfeld Adresse
Entfernung Behindertenparkplatz	integer	augsburgbarrierefrei:entfernungbehindertenparkplatz=* vorübergehend	Wert wurde erstmal übernommen, wird aber vorauss. nicht in osm importiert, da indirekt über Routing oder Entfernungsmessung dynamisch zu ermitteln
nächste Haltestelle	integer	-	Feld wird nicht übernommen
Internet	text	url=*
Problem	boolean	FIXME=Problem ohne weitere Angaben, siehe ggfs. vorhandene zusätzlichen Key note
Vermerk	text	note:de=*

Engstelle

An einem Punkt werden Informationen zu einer Engstelle auf einem Fußweg beschrieben. Der Fußweg selbst ist i.d.R. NICHT in dieser oder einer anderen Datenstruktur vorhanden.

Eine Engstelle ist definiert als nutzbare Breite 1,20m oder weniger.

Die Verengung wird i.d.R. meist durch Angabe der Fußwegbreite umgesetzt, bei einzelnen Typen auch noch durch zusätzliche Tags. Auf der talk-de Mailingliste wurde dieser ähnliche Thread gefunden Engstelle taggen? Was für ein Barrier?

Feldname	Feldtyp	osm-Tagging	Bemerkungen
EngstelleID	ID	augsburgbarrierefrei:tabelle=Engstelle vorübergehend augsburgbarrierefrei:ref=* vorübergehend
Typ	2|3|4	1 (=Mauer-Bordstein) note:de=Hinweis: Engstelle zwischen Mauer und Bordstein 2 (=Mauer-Mauer) note:de=Hinweis: Engstelle zwischen zwei Mauern 3 (=Straßenmobiliar, Verkehrszeichen) barrier=bollard note:de=Hinweis: Engstelle wegen Straßenmobiliar oder Verkehrszeichen 4 (=sonstiges) node:de=Hinweis: Engstelle, Grund unbekannt	OFFEN: noch unklar, ob als Barrier oder einfach den Weg (ggfs. nicht vorhanden) an dieser Stelle entsprechend mit der Breite zu taggen, siehe Feld Breite. Die Breite reicht für das Routing aus. Ich habe an dem Engstellen-Punkt den Fußweg für je 1 Meter in beide Richtungen als Segment gesplittet und diesem die Breite zugeordnet. Ich starte einen Versuch, die Stelle noch als traffic_calming=choker auszuzeichnen, damit dies evtl. in den Standardkarten oder in später zu erstellenden Spezialkarten einfach angezeigt werden kann.
Breite	integer (Einheit [cm])	width=* in Format x.x(x) Einheit [m]
Problem	boolean	FIXME=Problem ohne weitere Angaben, siehe ggfs. vorhandene zusätzlichen Key note
Vermerk	text	FIXME=* note:de=*	Hinweis: Bei dieser Datenstruktur sind die Vermerke sehr aussagekräftig und werden zusätzlich mit Key FIXME gesetzt, damit die Bemerkungen schneller abgearbeitet werden. Zum Teil gibt es dort auch Hinweise auf den Teil des Fußwegs, der evtl. in keiner Datenstruktur in diesem Projekt vorkommt (es gibt u.a. offenbar zwei Datensätze in dieser Datenstruktur, die Anfang und Ende einer Engstelle markieren, sind also in openstreetmap dann als Weg umzusetzen).

Haltestelle

OFFEN: Beschreibung folgt noch, bis jetzt wurde noch kein Testexport durchgeführt, weil wahrscheinlich keine zusätzlichen Daten vorliegen zum OSM-Stand. Das wird aber noch geprüft.

Feldname	Feldtyp	osm-Tagging	Bemerkungen
HaltestelleID	ID	augsburgbarrierefrei:tabelle=Haltestelle vorübergehend augsburgbarrierefrei:ref=* vorübergehend
Name	text	name=*
Linien	text	-	numerische Auflistung der Tram- und Bus-Linien, Trennzeichen ist Komma ",". Die Regionalbusverbindungen sind nicht einzeln aufgeführt, dann kommt nur der Text "Regionalbusse" vor
Internet	text	-	In den Feldern steht nur ein Teil des Feldinhalts von Name, nicht auswertbar, vermutlich Importfehler in DB.
Problem	boolean	FIXME=Problem ohne weitere Angaben, siehe ggfs. vorhandene zusätzlichen Key note
Vermerk	text	note:de=*	Zwei Kommentare vorhanden, können ausgewertet werden, da kleiner Hinweis auf schlechten Haltestellen-Zugang für Gehbehinderte.

Längsneigung

Es liegen Flächen vor, die einen Wegabschnitt mit einer Steigung und deren Richtung beschreibt.

Die Flächen müssen mit den anderen Flächen-Datenstrukturen (Belag und Querneigung) vor dem Import abgeglichen werden, da diese manchmal identisch sind oder eine andere Fläche teilweise überschneiden, manchmal für eine Teilfläche z.B. noch eine Querneigung erfasst wurde.

Die Neigungsrichtung wird in 8 Himmelsrichtungen (0 für Nord, 45 für Nordost, 90 für Ost, 135 für Südost etc.) beschrieben. Diese Angabe wird für die Fläche beibehalten.

Der Neigungsbetrag wird auf den i.d.R. vorhandenen Wegabschnitt übertragen, dabei ist die Digitalisierrichtung zu achten.

Feldname	Feldtyp	osm-Tagging	Bemerkungen
		highway=pedestrian area=yes	Wert von Key highway muss ggfs. anpasst werden (kann auch footway, residential, living_street etc. sein)
LaengsneigungID	ID	augsburgbarrierefrei:tabelle=Laengsneigung vorübergehend augsburgbarrierefrei:ref=* vorübergehend
Neigungsbetrag	double (praktisch mit 0 bis 1 Nachkommastelle, dezimal mit Komma (,)	incline=* (im Format x(.x)% (mit Dezimaltrennzeichen Punkt und MIT % (Prozent-)Zeichen	OFFEN: wahrscheinlich Neigungsbetrag in %, wird naber noch mit der Uni geklärt. Der Neigungsbetrag wird auf den i.d.R. vorhandenen Wegabschnitt übertragen, dabei ist die Digitalisierrichtung zu achten.
Neigungsrichtung	45|90|135|180|225|270|315)	augsburgbarrierefrei:richtung=*	siehe OSM-Tagging bei tourism=information Unterbereich Hinweisschilder. Dort werden Keys für 8 Himmelsrichtungen angegeben.
Problem	boolean	FIXME=Problem ohne weitere Angaben, siehe ggfs. vorhandene zusätzlichen Key note
Vermerk	text	note:de=*

Parkhaus

Die Parkhäuser liegen als Knoten vor. Das einzige relevante Feld ist die Angabe der Anzahl Behindertenparkplätze.

Feldname	Feldtyp	osm-Tagging	Bemerkungen
		amenity=parking	Die Art des Parkhauses muß noch ergänzt werden: Tiefgarage parking=underground ebenerdig parking=surface Parkhaus multi-storey=*
ParkhausID	ID	augsburgbarrierefrei:tabelle=Parkhaus vorübergehend augsburgbarrierefrei:ref=* vorübergehend
name	text	name=*
Adresse	text in Form Straße Hausnummer	augsburgbarrierefrei:parkhausadresse=*	Feldinhalt bei Import in normale OSM-Tags addr:street=* und addr:housenumber=* konvertieren
Öffnungszeiten	text in Form	augsburgbarrierefrei:oeffnungszeiten=*	Feldinhalt bei Import in OSM-Tag opening_hours=* konvertieren
AnzahlBehindertenparkplaetze	integer	capacity:disabled=*
Problem	boolean	FIXME=Problem ohne weitere Angaben, siehe ggfs. vorhandene zusätzlichen Key note
Vermerk	text	note:de=*

Parkplatz

Die Parkplätze liegen als Knoten vor.

Feldname	Feldtyp	osm-Tagging	Bemerkungen
		amenity=parking parking=surface
ParkplatzID	ID	augsburgbarrierefrei:tabelle=Parkplatz vorübergehend augsburgbarrierefrei:ref=* vorübergehend
Anzahl	integer	capacity=* capacity:disabled=*
Breite	integer (Einheit in [cm]	width=* im Format x.x(x) in Einheit [m]	unklar, ob Breite je Parkplatz oder insgesamt, Angaben schwanken von Anzahl=Breite: 1=280 bis 2=250
nichtbarrierefreierZugang	boolean	??? FIXME=Zugang nicht barrierefrei. Bitte prüfen	in zwei Fällen ist das Feld gesetzt. Entweder ganz wheelchair=no oder über access=??? setzen. Am besten vor Ort prüfen.
Problem	boolean	FIXME=Problem ohne weitere Angaben, siehe ggfs. vorhandene zusätzlichen Key note
Vermerk	text	note:de=*

Querneigung

Es liegen Flächen vor, die einen Wegabschnitt mit einer Querneigung und deren Richtung beschreibt.

Die Flächen müssen mit den anderen Flächen-Datenstrukturen (Belag und Längsneigung) vor dem Import abgeglichen werden, da diese manchmal identisch sind oder eine andere Fläche teilweise überschneiden, manchmal für eine Teilfläche z.B. noch eine Längsneigung erfasst wurde.

Die Neigungsrichtung wird in 8 Himmelsrichtungen (0 für Nord, 45 für Nordost, 90 für Ost, 135 für Südost etc.) beschrieben. Diese Angabe wird für die Fläche beibehalten.

OFFEN: (OSM-Tag gibt es noch nicht. Dann:) Der Neigungsbetrag würde auf den i.d.R. vorhandenen Wegabschnitt übertragen, dabei ist die Digitalisierrichtung zu achten.

Feldname	Feldtyp	osm-Tagging	Bemerkungen
		highway=pedestrian area=yes	Wert von Key highway muss ggfs. anpasst werden (kann auch footway, residential, living_street etc. sein)
QuerneigungID	ID	augsburgbarrierefrei:tabelle=Querneigung vorübergehend augsburgbarrierefrei:ref=* vorübergehend
Neigungsbetrag	double (praktisch mit 0 bis 1 Nachkommastelle, dezimal mit Komma (,)	augsburgbarrierefrei:sideincline=* (im Format x(.x)% (mit Dezimaltrennzeichen Punkt und MIT % (Prozent-)Zeichen	Update 12.07.2010: incline:left und incline:right wird jetzt genommen, da left: und right: sich bei einigen Definition auf ein Objekt links oder rechts relativ zum aktuellen Objekt bezieht, genommen wird. Der Neigungsbetrag wird auf den i.d.R. vorhandenen Wegabschnitt übertragen, dabei ist die Digitalisierrichtung zu achten. Eigenes Tag vor einigen Wochen faktisch 2mal angewandt, left:incline bzw. right:incline. Nach OSM-Tag Definition setzen.
Neigungsrichtung	45|90|135|180|225|270|315)	augsburgbarrierefrei:richtung=*	siehe OSM-Tagging bei tourism=information Unterbereich Hinweisschilder. Dort werden Keys für 8 Himmelsrichtungen angegeben.
Problem	boolean	FIXME=Problem ohne weitere Angaben, siehe ggfs. vorhandene zusätzlichen Key note
Vermerk	text	note:de=*

Rinne

In den meisten Fällen eine längs zum Fußweg verlaufende Regenablaufrinne, die schwer zu überqueren ist für Gehbehinderte.

Die Rinne liegt als offener Weg vor.

Technisch ist es ein Hindernis, also osm-Key barrier. Allerdings gibt es noch keinen entsprechenden Wert. Auch im deutschen und englischen Tagwatch keinen sinnvollen Wert gefunden. Der vermutlich passende englische Begriff könnte gutter sein.

Feldname	Feldtyp	osm-Tagging	Bemerkungen
		barrier=yes note:de=Hinweis: Regenablaufrinne: möglicherweise Hindernis für Überquerung
RinneID	ID	augsburgbarrierefrei:tabelle=Rinne vorübergehend augsburgbarrierefrei:ref=* vorübergehend
Breite	integer (in Einheit [cm]	width=* im Format x.x(x), Einheit in [m]
Tiefe	integer (in Einheit [cm]	height=* (negativer Wert !) im Format x.x(x), Einheit in [m]
besondereProblemstelle	boolean	FIXME=besondere Problemstelle ohne weitere Angaben, siehe ggfs. vorhandene zusätzlichen Key note	faktisch nicht gesetzt in den Datensätzen
Problem	boolean	FIXME=Problem ohne weitere Angaben, siehe ggfs. vorhandene zusätzlichen Key note
Vermerk	text	note:de=*

Händische Nachbearbeitung nach Dateitransformation nach osm: Die Rinnen liegen als offene Wege vor, aber ca. bei der Hälfte der Länge hat ein Knoten nochmal dieselben Keys/Values und wird daher in JOSM extra dargestellt. Bei den extra attributierten Knoten wurden die Keys/Values entfernt.

Ruhebank

Punkt einer Ruhebank.

OFFEN: (Mit Uni abkären, im Erfassungsbogen gibt es keine Abfrage dazu) Ich gehe davon aus, daß eine Bank, wenn nicht anders angegeben (siehe Vermerk), eine Rückenlehne hat und dies wird entsprechend mit getaggt.

Im Feld Vermerk wird u.a. angegeben, wenn eine Lehne nicht vorhanden, dies ist nachzuerfassen beim osm-Import.

Feldname	Feldtyp	osm-Tagging	Bemerkungen
		amenity=bench backrest=yes
RuhebankID	ID	augsburgbarrierefrei:tabelle=Ruhebank vorübergehend augsburgbarrierefrei:ref=* vorübergehend
Problem	boolean	FIXME=Problem ohne weitere Angaben, siehe ggfs. vorhandene zusätzlichen Key note
Vermerk	text	note:de=*

sonstiges Hindernis

Es kommen nur zwei Datensätze vor. In beiden Fällen geht es um Straßenbahnschienen, die nach Grad der Gehbehinderung als erschwert oder nicht passierbar eingestuft sind.

Feldname	Feldtyp	osm-Tagging	Bemerkungen
		barrier=yes
sonstigesHinternisID	ID	augsburgbarrierefrei:tabelle=sonstigesHindernis vorübergehend augsburgbarrierefrei:ref=* vorübergehend
Beschreibung	text	note:de=*
Einstufung	integer 1..5	1 (= mit dem Rollstuhl Erschwernis) wheelchair=limited 2 (= mit dem Rollstuhl besondere Erschwernis) wheelchair=limited note:de=Hinweis: mit dem Rollstuhl besondere Erschwernis 3 (= mit dem Rollstuhl unmöglich / für Gehbehinderte keine/leichte Erschwernis) wheelchair=no note:de=Hinweis: für Gehbehinderte keine/leichte Erschwernis 4 (= mit dem Rollstuhl unmöglich / für Gehbehinderte Erschwernis) wheelchair=no note:de=Hinweis: für Gehbehinderte Erschwernis 5 (= mit dem Rollstuhl unmöglich / für Gehbehinderte besondere Erschwernis) wheelchair=no note:de=Hinweis: für Gehbehinderte besondere Erschwernis	OFFEN: evtl. zusätzliches OSM-Tagging für verschiedene Grade an Gehbehinderung (z.B. Rollator-Nutzung, etc.) einführen
Problem	boolean	FIXME=Problem ohne weitere Angaben, siehe ggfs. vorhandene zusätzlichen Key note
Vermerk	text	note:de=*

Händische Nachbearbeitung nach Dateitransformation nach osm: Die sonstigen Hindernisse liegen als offene Wege vor, aber ca. bei der Hälfte der Länge hat ein Knoten nochmal dieselben Keys/Values und wird daher in JOSM extra dargestellt. Bei den extra attributierten Knoten wurden die Keys/Values entfernt.

Stufe

Eine Stufe wurde als offener Weg erfasst, außerdem kommt in der Mitte des Weges noch ein Knoten vor, dem die selben Werte zugeordnet sind.

WICHTIG: Nur der Knoten in der Mitte zählt als Stufe. Der offene Weg ist nur für die Kartendarstellung im barrierefreien Stadtplan erfasst worden und wird nicht in openstreetmap importiert!

Die Knoten sind auf Lagerichtigkeit zu überprüfen.

Feldname	Feldtyp	osm-Tagging	Bemerkungen
		highway=steps step_count=1
StufeID	ID	augsburgbarrierefrei:tabelle=Stufe vorübergehend augsburgbarrierefrei:ref=* vorübergehend
Stufenhoehe	integer (Einheit [cm])	height=* im Format x(.xx) mit Dezimaltrennzeichen Punkt
rutschiger_und_oder_unebener_Belag	boolean	note:de=Warnung: Belag ist rutschig oder uneben	prüfen, ob bei smoothness oder surface ein Value existiert, aber vermutlich eher nicht
leicht_zu_uebersehen	boolean	note:de=Warnung: Stufe ist leicht zu übersehen
Problem	boolean	FIXME=Problem ohne weitere Angaben, siehe ggfs. vorhandene zusätzlichen Key note
Vermerk	text	note:de=*

Taxistand

Markierung eines Taxistands als Punkt.

Feldname	Feldtyp	osm-Tagging	Bemerkungen
		amenity=taxi
TaxistandID	ID	augsburgbarrierefrei:tabelle=Taxistand vorübergehend augsburgbarrierefrei:ref=* vorübergehend
Zeiten	text in Textform, zu konvertieren in Zielformat	augsburgbarrierefrei:taxistandzeiten=*	später zu konvertieren in Ziel-Tag presence=*, dort ist das Tag-Format angegeben (wie opening_hours)
Problem	boolean	FIXME=Problem ohne weitere Angaben, siehe ggfs. vorhandene zusätzlichen Key note
Vermerk	text	note:de=*

Telefon

Position einer Telefonzelle als Punkt.

Nur im Feld Vermerk machmal ein Hinweis bzgl. Zugangsmöglichkeit für Gehbehinderte.

Feldname	Feldtyp	osm-Tagging	Bemerkungen
		amenity=telephone
TelefonID	ID	augsburgbarrierefrei:tabelle=Telefon vorübergehend augsburgbarrierefrei:ref=* vorübergehend
Typ	2	1 (=Zelle) covered=booth 2 (=offen) covered=no FIXME=*
Problem	boolean	FIXME=Problem ohne weitere Angaben, siehe ggfs. vorhandene zusätzlichen Key note
Vermerk	text	FIXME=*	Nur im Feld Vermerk machmal ein Hinweis bzgl. Zugangsmöglichkeit für Gehbehinderte, daher wird in diesem Fall der Inhalt als FIXME getaggt zur Prüfung und ggfs. nach-taggen.

Treppe

Eine Treppe wurde als offener Weg erfasst, außerdem kommt in der Mitte des Weges noch ein Knoten vor, dem die selben Werte zugeordnet sind.

Der Verlauf der Treppe ist nicht eingezeichnet, sondern der "Weg" im Quell-GIS stellt eine etwa senkrechte Linie zum eigentlichen Treppenverlauf dar (um in der Karte eine starke Hindernis-Optik zu erlangen). Die Treppe am Rathausplatz Richtung Elias-Holl-Platz wird durch zwei Treppen am oberen und am unteren Ende dargestellt.

Daher sind die Treppen-Wege fast nicht importierbar. Es wird dringend angeraten, diese erst nach einer vor-Ort Besichtigung mit neu erfassten Daten zu importieren.

Es werden diverse zusätzliche Angaben gemacht inkl. Problemaspekte, die die Nutzung einschränken können.

Feldname	Feldtyp	osm-Tagging	Bemerkungen
		highway=steps	OFFEN: noch nicht geprüft, vermutlich Punkt-Objekt, daher vermutlich weiteres Tag notwendig FIXME=Erfassung: Treppe bitte einzeichnen
TreppeID	ID	augsburgbarrierefrei:tabelle=Treppe vorübergehend augsburgbarrierefrei:ref=* vorübergehend
Stufenanzahl	integer	step_count=*
Stufenhoehe	integer Einheit [cm]	augsburgbarrierefrei:treppe_stufenhoehe=* im Format x.x(x) [m]	OFFEN: evtl. OSM Tagging ergänzen
Stufentiefe	integer Einheit [cm]	augsburgbarrierefrei:treppe_stufentiefe=* im Format x.x(x) [m]	OFFEN: evtl. OSM Tagging ergänzen
nicht_ausreichender_Handlauf	boolean	handrail=limited note:de=Information: Handlauf nicht ausreichend
nicht_ausreichende_Beleuchtung	boolean	lit=limited note:de=Information: Beleuchtung nicht ausreichend
unsicherer Belag	boolean	note:de=Warnung: Belag unsicher
Unterschiede in den Stufen	boolean	note:de=Warnung: Stufen unterschiedlich
Problem	boolean	FIXME=Problem ohne weitere Angaben, siehe ggfs. vorhandene zusätzlichen Key note
Vermerk	text	note:de=*

WC

Position eines öffentlichen oder halböffentlichen WCs als Punkt.

Hinweis: fast alle Datensätze sind im Feld Vermerk mit CHECKEN versehen, also nach Übernahme vor Ort Kontrolle nötig.

Feldname	Feldtyp	osm-Tagging	Bemerkungen
		amenity=toilets
WCID	ID	augsburgbarrierefrei:tabelle=WC vorübergehend augsburgbarrierefrei:ref=* vorübergehend
Typ	2	1 (=öffentlich) - 2 (=halböffentlich) access=permissive	für öffentlich nachsehen bei access, ob public vorhanden ist, dann setzen, wenn auch vermutlich selbstverständlich bzw. standard
Problem	boolean	FIXME=Problem ohne weitere Angaben, siehe ggfs. vorhandene zusätzlichen Key note
Vermerk	text	FIXME=*	Hinweis: auf FIXME gesetzt, da fast alle Datensätze im Feld Vermerk mit CHECKEN versehen sind, also nach Übernahme vor Ort Kontrolle nötig.

Zugang zu Einrichtungen

Allgemeines

Im barrierefreien Stadtplan ist für jede #Einrichtung Einrichtung nur ein Zugang definiert und zwar der beste Zugang hinsichtlich Barrierefreiheit.

Der Zugang zum Eingang zu einer Einrichtung ist als Punktkoodinate bei Zugangebenerdig, ZugangStufe oder ZugangTreppe definiert. Im Datensatz ist die ID der Einrichtung vorhanden.

Der Eingang selbst (die Türart) zu einér Einrichtung ist in ZugangstuereFluegel oder ZugangstuereSchieb definiert inkl. etlicher Details. Es wird auf ein extra Schema zur Erfassung verwiesen, auf dem die diversen Messwerte erläutert werden.

OFFEN: es ist noch unklar, ob der Zugang zum Eingang oder der Eingang selbst als Punkt genau definiert wurde. In jedem Fall sind beide Punkte um 3.0 entfernt ost/west verschoben. Dies erfolgte wegen der aktuellen Kartendarstellung im barrierefreien Stadtplan.

Im Fall der Zugangsarten ZugangStufe und ZugangTreppe muss händisch nacherfasst werden, um den Weg der Stufe oder der Treppe in openstreetmap darzustellen.

Zugangebenerdig

Punktkoordinate eines Zugangs ohne Höhendifferenz zu einer Einrichtung (siehe Datenstruktur Einrichtung).

Es werden Angaben zum Eingang angegeben und es wird eine direkte Einstufung der Barrierefreiheit (per Schlüssel) angegeben.

OFFEN: Es muß mit der Universität noch geklärt werden, ob die Koordinaten der Zugang..-Tabellen oder die der Zugangstuere...-Tabellen stimmt. Die Koordinaten sind um genau 3.0m verschoben, um optisch im aktuellen barrierefreien Stadtplan die Symbole beeinander zu zeigen.

Feldname	Feldtyp	osm-Tagging	Bemerkungen
		building=entrance Am Objekt Einrichtung zusätzliches Tagging HÄNDISCH ERFASSEN: building_entrance:ramp=yes Link: Proposed features/building entrance	OFFEN: bei Uni nachfragen, ob als Koordinate der Gebäudezugang genommen wurde.
ZugangebenerdigID	ID	augsburgbarrierefrei:tabelle=Zugangebenerdig vorübergehend augsburgbarrierefrei:ref=* vorübergehend
EinrichtungID	integer	augsburgbarrierefrei:referenz_einrichtungid=*
Haupteingang	boolean	augsburgbarrierefrei:haupteingang_ebenerdigzugang=yes { false: {tag|note:de|Information: Nebeneingang ebenerdig erreichbar}} { true: {tag|note:de|Information: Haupteingang ebenerdig erreichbar}}	OFFEN: evtl. OSM Tagging ergänzen
Klingel	boolean	augsburgbarrierefrei:eingang_klingel=yes note:de=Information: Klingel am Eingang für Zugang vorhanden Am Objekt Einrichtung zusätzliches Tagging HÄNDISCH ERFASSEN: building_entrance:access_button=yes	OFFEN: evtl. OSM Tagging ergänzen
Barrierefreiheit	2|3	1 (=nicht barrierefrei) augsburgbarrierefrei:barrierefrei=no 2 (=bedingt barrierefrei) augsburgbarrierefrei:barrierefrei=limited 3 (=barrierefrei) augsburgbarrierefrei:barrierefrei=yes	OFFEN: mit Uni klären, welche Definitionsgrundlage hier genommen wurde
Problem	boolean	FIXME=Problem ohne weitere Angaben, siehe ggfs. vorhandene zusätzlichen Key note
Vermerk	text	note:de=*

Zugangrampe

Punktkoordinate einer Zugangsrampe zu einer Einrichtung (siehe Datenstruktur Einrichtung).

Es werden diverse Angaben zur Rampe angegeben inkl. Problemaspekte, die die Nutzung einschränken können.

OFFEN: Es muß mit der Universität noch geklärt werden, ob die Koordinaten der Zugang..-Tabellen oder die der Zugangstuere...-Tabellen stimmt. Die Koordinaten sind um genau 3.0m verschoben, um optisch im aktuellen barrierefreien Stadtplan die Symbole beeinander zu zeigen.

Feldname	Feldtyp	osm-Tagging	Bemerkungen
		highway=footway Am Objekt Einrichtung zusätzliches Tagging HÄNDISCH ERFASSEN: building_entrance:ramp=yes	OFFEN: noch nicht geprüft, vermutlich Punkt-Objekt, daher vermutlich weiteres Tag notwendig FIXME=Erfassung: Rampe als Fußweg einzeichnen,bitte
ZugangrampeID	ID	augsburgbarrierefrei:tabelle=Zugangrampe vorübergehend augsburgbarrierefrei:ref=* vorübergehend
EinrichtungID	integer	augsburgbarrierefrei:referenz_einrichtungid=*
Haupteingang	boolean	augsburgbarrierefrei:haupteingang_rampevorhanden=yes note:de=Information: Rampe führt zum Haupteingang	OFFEN: evtl. OSM Tagging ergänzen
Klingel	boolean	augsburgbarrierefrei:eingang_klingel=yes note:de=Information: Klingel am Eingang für Zugang vorhanden Am Objekt Einrichtung zusätzliches Tagging HÄNDISCH ERFASSEN: building_entrance:access_button=yes	OFFEN: evtl. OSM Tagging ergänzen
Laengsneigung	integer (Einheit in % vermutlich)	incline=* (im Format x(.x)% (mit Dezimaltrennzeichen Punkt und MIT % (Prozent-)Zeichen	OFFEN: mit Uni klären, ob Einheit in % ACHTUNG: mehrere Datensätze mit Längsneigung 0 (einer im Vermerk mit Hinweis auf Fahrstuhl). Entweder mehrere Fahrstühle oder Falsch-Erfassung, nachprüfen !
Querneigung	integer (Einheit in % vermutlich)	augsburgbarrierefrei:sideincline=* (im Format x(.x)% (mit Dezimaltrennzeichen Punkt und MIT % (Prozent-)Zeichen	incline:left=* bzw. incline:right=* siehe auch Datenstruktur Querneigung für OSM-Tagging.
Laenge	integer Einheit in [cm]	augsburgbarrierefrei:length=* im Format x(.xx) mit Dezimaltrennzeichen Punkt	vorübergehendes Tag, entfernen, wenn Rampe als Fußweg eingezeichnet ist Datensätze: 222 und 359: vermutlich fehlerhafte Eingabe in m statt cm, bei Uni prüfen lassen.
Breite	integer Einheit in [cm]	augsburgbarrierefrei:width=* im Format x(.xx) mit Dezimaltrennzeichen Punkt	vorübergehendes Tag, entfernen, wenn Rampe als Fußweg eingezeichnet ist, dann am Weg width=*
nicht_gerade	boolean	augsburgbarrierefrei:rampe_nicht_gerade=yes note:de=Information: Rampe ist nicht gerade
nicht_ausreichendes_Gelaender	boolean	handrail=limited note:de=Information: Geländer nicht ausreichend
nicht_ausreichende_Beleuchtung	boolean	lit=limited note:de=Information: Beleuchtung nicht ausreichend
rutschiger_unebener_Belag	boolean	??? note:de=Warnung: Belag rutschig oder uneben
Problem	boolean	FIXME=Problem ohne weitere Angaben, siehe ggfs. vorhandene zusätzlichen Key note
Vermerk	text	note:de=*

Zugangstufe

Punktkoordinate einer Zugangsstufe zu einer Einrichtung (siehe Datenstruktur Einrichtung). Der Zugang zum Gebäude ist also nur über eine einzelne Stufe möglich. Diese wird hier im näheren beschrieben.

Es werden diverse Angaben zur Stufe angegeben inkl. Problemaspekte, die den Zugang verhindern oder einschränken können.

OFFEN: Es muß mit der Universität noch geklärt werden, ob die Koordinaten der Zugang..-Tabellen oder die der Zugangstuere...-Tabellen stimmt. Die Koordinaten sind um genau 3.0m verschoben, um optisch im aktuellen barrierefreien Stadtplan die Symbole beeinander zu zeigen.

Feldname	Feldtyp	osm-Tagging	Bemerkungen
		highway=steps FIXME=Erfassung: Treppe bitte manuell nacherfassen
ZugangstufeID	ID	augsburgbarrierefrei:tabelle=Zugangstufe vorübergehend augsburgbarrierefrei:ref=* vorübergehend
EinrichtungID	ID	augsburgbarrierefrei:tabelle=Einrichtung vorübergehend augsburgbarrierefrei:ref=* vorübergehend
Haupteingang	leer	augsburgbarrierefrei:haupteingang_stufevorhanden=yes 1: note:de=Information: Haupteingang nur über einzelne Stufe erreichbar leer: note:de=Information: Nebeneingang nur über einzelne Stufe erreichbar	OFFEN: evtl. OSM Tagging ergänzen OFFEN: prüfen, ob zwischen false und true korrekt unterschiedlich getaggt wird (false = leeres Feld)
Klingel	boolean	augsburgbarrierefrei:eingang_klingel=yes note:de=Information: Klingel am Eingang für Zugang vorhanden Am Objekt Einrichtung zusätzliches Tagging HÄNDISCH ERFASSEN: building_entrance:access_button=yes	OFFEN: evtl. OSM Tagging ergänzen
Stufenhoehe	integer (Einheit [cm])	height=* im Format x(.xx) Einheit [m] mit Dezimaltrennzeichen Punkt
rutschiger_und_oder_unebener_Belag	boolean	note:de=Warnung: Belag ist rutschig oder uneben	prüfen, ob bei smoothness oder surface ein Value existiert, aber vermutlich eher nicht
leicht_zu_uebersehen	boolean	note:de=Warnung: Stufe ist leicht zu übersehen
Problem	boolean	FIXME=Problem ohne weitere Angaben, siehe ggfs. vorhandene zusätzlichen Key note
Vermerk	text	note:de=*

Zugangtreppe

Punktkoordinate einer Zugangstreppe zu einer Einrichtung (siehe Datenstruktur Einrichtung).

Es werden diverse Angaben zur Treppe angegeben inkl. Problemaspekte.

OFFEN: Es muß mit der Universität noch geklärt werden, ob die Koordinaten der Zugang..-Tabellen oder die der Zugangstuere...-Tabellen stimmt. Die Koordinaten sind um genau 3.0m verschoben, um optisch im aktuellen barrierefreien Stadtplan die Symbole beeinander zu zeigen.

Feldname	Feldtyp	osm-Tagging	Bemerkungen
		highway=steps	OFFEN: noch nicht geprüft, vermutlich Punkt-Objekt, daher vermutlich weiteres Tag notwendig FIXME=Erfassung: Treppe bitte einzeichnen
ZugangtreppeID	ID	augsburgbarrierefrei:tabelle=Zugangtreppe vorübergehend augsburgbarrierefrei:ref=* vorübergehend
EinrichtungID	ID	augsburgbarrierefrei:tabelle=Einrichtung vorübergehend augsburgbarrierefrei:ref=* vorübergehend
Haupteingang	leer (boolean)	augsburgbarrierefrei:haupteingang_treppevorhanden=yes 1: note:de=Information: Haupteingang nur über Treppe erreichbar leer: note:de=Information: Nebeneingang nur über Treppe erreichbar	OFFEN: evtl. OSM Tagging ergänzen OFFEN: prüfen, ob zwischen false und true korrekt unterschiedlich getaggt wird (false = leeres Feld)
Klingel	boolean	augsburgbarrierefrei:eingang_klingel=yes note:de=Information: Klingel am Eingang für Zugang vorhanden Am Objekt Einrichtung zusätzliches Tagging HÄNDISCH ERFASSEN: building_entrance:access_button=yes	OFFEN: evtl. OSM Tagging ergänzen
Stufenanzahl	integer	step_count=*
Stufenhoehe	integer Einheit [cm]	augsburgbarrierefrei:treppe_stufenhoehe=* im Format x.x(x) [m]	OFFEN: evtl. OSM Tagging ergänzen
Stufentiefe	integer Einheit [cm]	augsburgbarrierefrei:treppe_stufentiefe=* im Format x.x(x) [m]	OFFEN: evtl. OSM Tagging ergänzen
nicht_ausreichender_Handlauf	boolean	handrail=limited note:de=Information: Handlauf nicht ausreichend
nicht_ausreichende_Beleuchtung	boolean	lit=limited note:de=Information: Beleuchtung nicht ausreichend
unsicherer Belag	boolean	note:de=Warnung: Belag unsicher
Unterschiede in den Stufen	boolean	note:de=Warnung: Stufen unterschiedlich
Problem	boolean	FIXME=Problem ohne weitere Angaben, siehe ggfs. vorhandene zusätzlichen Key note
Vermerk	text	note:de=*

ZugangstuereDreh

Es wurden keine Drehtüren bei Erfassungen gefunden, daher keine Sachdaten und Geometriedaten hierzu vorhanden.

ZugangstuereFluegel

Punktkoordinate des Eingangs (eine Flügeltüre) zu einer Einrichtung (siehe Datenstruktur Einrichtung).

Es werden diverse Angaben zur Türe angegeben inkl. Problemaspekte. Für die Erfassung einer Flügeltüre wird dieser Erfassungsbogen für Eingänge eingesetzt, dort ist eine Zeichnung mit allen zu messenden Werten vorhanden, bitte dort die Bedeutung der weiter unten aufgeführten Felder nachsehen.

OFFEN: Es muß mit der Universität noch geklärt werden, ob die Koordinaten der Zugang..-Tabellen oder die der Zugangstuere...-Tabellen stimmt. Die Koordinaten sind um genau 3.0m verschoben, um optisch im aktuellen barrierefreien Stadtplan die Symbole beeinander zu zeigen.

Feldname	Feldtyp	osm-Tagging	Bemerkungen
		building=entrance
ZugangstuereFluegelID	ID	augsburgbarrierefrei:tabelle=ZugangstuereFluegel vorübergehend augsburgbarrierefrei:ref=* vorübergehend
ZugangID	ID	augsburgbarrierefrei:referenz_zugang=* vorübergehend	Fremdschlüssel zu ID-Feld in einer der Datenstrukturen Zugangebenerdig, ZugangStufe oder ZugangTreppe
Typ	6 (integer)	augsburgbarrierefrei:haupteingang_treppevorhanden=yes 5: {tag|augsburgbarrierefrei:fluegeltuere_gehtnach|innen}} 6: {tag|augsburgbarrierefrei:fluegeltuere_gehtnach|innen}}	OFFEN: evtl. OSM Tagging ergänzen
Durchgangsbreite	integer Einheit [cm]	augsburgbarrierefrei:fluegeltuere_durchgangsbreite=* im Format x.x(x) [m]	OFFEN: evtl. OSM Tagging ergänzen
Höhe Türgriff	integer Einheit [cm]	augsburgbarrierefrei:fluegeltuere_hoehetuergriff=* im Format x.x(x) [m]	OFFEN: evtl. OSM Tagging ergänzen
nicht_ausreichender_Tuergriff	leer	augsburgbarrierefrei:eingang_klingel=yes 1: note:de=Hinweis: Türgriff nicht ausreichend	OFFEN: evtl. OSM Tagging ergänzen
Kraftaufwand_beim_Oeffnen	1|2|3 (integer)	augsburgbarrierefrei:haupteingang_treppevorhanden=yes -1: augsburgbarrierefrei:fluegeltuere_kraftaufwandoeffnen=automatik 1: augsburgbarrierefrei:fluegeltuere_kraftaufwandoeffnen=leicht 2: augsburgbarrierefrei:fluegeltuere_kraftaufwandoeffnen=mittel 3: augsburgbarrierefrei:fluegeltuere_kraftaufwandoeffnen=schwer	OFFEN: evtl. OSM Tagging ergänzen
Schliesszeit	2|3 (integer)	augsburgbarrierefrei:haupteingang_treppevorhanden=yes 1: augsburgbarrierefrei:fluegeltuere_schliesszeit=lang 2: augsburgbarrierefrei:fluegeltuere_schliesszeit=mittel 3: augsburgbarrierefrei:fluegeltuere_schliesszeit=kurz	OFFEN: evtl. OSM Tagging ergänzen
Automatik	leer (boolean)	1: building_entrance:auto_open=yes leer: building_entrance:auto_open=no
Automatik_offenet_nicht_rechtzeitig	leer (boolean)	note:de=Hinweis: Automatik-Türe öffnet nicht rechtzeitig
Tuerseite_Breite	integer Einheit [cm]	augsburgbarrierefrei:fluegeltuere_tuerseitebreite=* im Format x.x(x) [m]	OFFEN: evtl. OSM Tagging ergänzen
Tuerseite_Tiefe	integer Einheit [cm]	augsburgbarrierefrei:fluegeltuere_tuerseitetiefe=* im Format x.x(x) [m]	OFFEN: evtl. OSM Tagging ergänzen
Tuerseite_Breite_neben_Tuer	integer Einheit [cm]	augsburgbarrierefrei:fluegeltuere_tuerseitebreitenebentuer=* im Format x.x(x) [m]	OFFEN: evtl. OSM Tagging ergänzen
Rueckseite_Breite	integer Einheit [cm]	augsburgbarrierefrei:fluegeltuere_rueckseitebreite=* im Format x.x(x) [m]	OFFEN: evtl. OSM Tagging ergänzen
Rueckseite_Tiefe	integer Einheit [cm]	augsburgbarrierefrei:fluegeltuere_rueckseitetiefe=* im Format x.x(x) [m]	OFFEN: evtl. OSM Tagging ergänzen
Rueckseite_Breite_neben_Tuer	integer Einheit [cm]	augsburgbarrierefrei:fluegeltuere_rueckseitebreitenebentuer=* im Format x.x(x) [m]	OFFEN: evtl. OSM Tagging ergänzen
Tuersturz_Tiefe	integer Einheit [cm]	augsburgbarrierefrei:fluegeltuere_tuersturztiefe=* im Format x.x(x) [m]	OFFEN: evtl. OSM Tagging ergänzen
Problem	boolean	FIXME=Problem ohne weitere Angaben, siehe ggfs. vorhandene zusätzlichen Key note
Vermerk	text	note:de=*

ZugangstuereSchieb

Punktkoordinate des Eingangs (eine Schiebtüre) zu einer Einrichtung (siehe Datenstruktur Einrichtung).

Es werden diverse Angaben zur Türe angegeben inkl. Problemaspekte. Für die Erfassung einer Schiebtüre wird dieser Erfassungsbogen für Eingänge eingesetzt, dort ist eine Zeichnung mit allen zu messenden Werten vorhanden, bitte dort die Bedeutung der weiter unten aufgeführten Felder nachsehen.

OFFEN: Es muß mit der Universität noch geklärt werden, ob die Koordinaten der Zugang..-Tabellen oder die der Zugangstuere...-Tabellen stimmt. Die Koordinaten sind um genau 3.0m verschoben, um optisch im aktuellen barrierefreien Stadtplan die Symbole beeinander zu zeigen.

Feldname	Feldtyp	osm-Tagging	Bemerkungen
		building=entrance
ZugangstuereSchiebID	ID	augsburgbarrierefrei:tabelle=ZugangstuereSchieb vorübergehend augsburgbarrierefrei:ref=* vorübergehend
ZugangID	ID	augsburgbarrierefrei:referenz_zugang=* vorübergehend	Fremdschlüssel zu ID-Feld in einer der Datenstrukturen Zugangebenerdig, ZugangStufe oder ZugangTreppe
Durchgangsbreite	integer Einheit [cm]	augsburgbarrierefrei:schiebtuere_durchgangsbreite=* im Format x.x(x) [m]	OFFEN: evtl. OSM Tagging ergänzen
Höhe Türgriff	integer Einheit [cm]	augsburgbarrierefrei:schiebtuere_hoehetuergriff=* im Format x.x(x) [m]	OFFEN: evtl. OSM Tagging ergänzen
nicht_ausreichender_Tuergriff	leer	augsburgbarrierefrei:eingang_klingel=yes 1: note:de=Hinweis: Türgriff nicht ausreichend	OFFEN: evtl. OSM Tagging ergänzen
Kraftaufwand_beim_Oeffnen	1|2|3 (integer)	augsburgbarrierefrei:haupteingang_treppevorhanden=yes -1: augsburgbarrierefrei:schiebtuere_kraftaufwandoeffnen=automatik 1: augsburgbarrierefrei:schiebtuere_kraftaufwandoeffnen=leicht 2: augsburgbarrierefrei:schiebtuere_kraftaufwandoeffnen=mittel 3: augsburgbarrierefrei:schiebtuere_kraftaufwandoeffnen=schwer	OFFEN: evtl. OSM Tagging ergänzen
Schliesszeit	2|3 (integer)	augsburgbarrierefrei:haupteingang_treppevorhanden=yes 1: augsburgbarrierefrei:schiebtuere_schliesszeit=lang 2: augsburgbarrierefrei:schiebtuere_schliesszeit=mittel 3: augsburgbarrierefrei:schiebtuere_schliesszeit=kurz	OFFEN: evtl. OSM Tagging ergänzen
Automatik	leer (boolean)	1: building_entrance:auto_open=yes leer: building_entrance:auto_open=no
Automatik_offenet_nicht_rechtzeitig	leer (boolean)	note:de=Hinweis: Automatik-Türe öffnet nicht rechtzeitig
Bewegungsflaeche_vor_Breite	integer Einheit [cm]	augsburgbarrierefrei:schiebtuere_bewegflaechevorbreite=* im Format x.x(x) [m]	OFFEN: evtl. OSM Tagging ergänzen
Bewegungflaeche_vor_Tiefe	integer Einheit [cm]	augsburgbarrierefrei:schiebtuere_bewegflaechevortiefe=* im Format x.x(x) [m]	OFFEN: evtl. OSM Tagging ergänzen
Bewegungsflaeche_hinter_Breite	integer Einheit [cm]	augsburgbarrierefrei:schiebtuere_bewegflaechehinterbreite=* im Format x.x(x) [m]	OFFEN: evtl. OSM Tagging ergänzen
Bewegungsflaeche_hinter_Tiefe	integer Einheit [cm]	augsburgbarrierefrei:schiebtuere_bewegflaechehintertiefe=* im Format x.x(x) [m]	OFFEN: evtl. OSM Tagging ergänzen
geringste_Breite_neben_der_Tuer	integer Einheit [cm]	augsburgbarrierefrei:schiebtuere_geringstebreitenebentuer=* im Format x.x(x) [m]	OFFEN: evtl. OSM Tagging ergänzen
Problem	boolean	FIXME=Problem ohne weitere Angaben, siehe ggfs. vorhandene zusätzlichen Key note
Vermerk	text	note:de=*

Testimport

Allgemeines; Testgebiet

Es wurde vereinbart, zuerst in einem Testgebiet die Datenübernahme zu testne, um zu klären, wie aufwändig der Import und welche Schwierigkeiten aufreten können.

Das Testgebiet wurde durch folgende Straßenbegrenzungen definiert:

• westliche Beschränkung Anna-Straße
• nördlich Grottenau - Leonhardsberg
• östlich Oberer Graben
• südlich ca. Hallstraße

Dieses Gebiet wurde von mir gewählt, weil:

• im östlichen Bereich in den engen Gassen sind mehrfache Belag-Flächen pro Straße vorhanden, weil dort öfters Kopfsteinpflaster vorkommt und in der Mitte ein etwas besserer Bereich mit Betonplatten. Es liegt hier i.d.R. kein eigener Fußweg vor.
• im Bereich Annastraße kommt das Hindernis Rinne vor, dafür gibt es noch kein Tagging
• bei den Straßen der Außenbegrenzung gibt es auch Fußgängerüberquerungen, diese können mit importiert werden, stellen vorauss. aber kein Problem dar, deshalb keine größeren Straßen im Testgebiet mittendrin.
• Rathausplatz ist im Testgebiet enthalten. Dort sind bereits viele Details vorhanden, daher werden Probleme im Zusammenhang mit dem verschieben vorhandener Strukturen auftreten.
• Der Stadtmarkt ist nicht im Testgebiet, hier wird ein extra Aufwand erforderlich, falls dieser verschoben werden muß. Die Erfahrungen mit dem Rathausplatz werden dann helfen.
• Es sind Fußgängerzonen im Testgebiet enthalten.

Produktivkonvertierung 05.07.2010 und Bereitstellung Testgebiet (nur zur Ansicht)

Am 5.7. wurden die letzten Themen produktiv konvertiert.

Die Daten aller Themen stehen für das Testgebiet insgesamt in der osm-Datei Testdaten gezipt 59kb zur Verfügung.

Bitte die Daten nur betrachten, keine Datenimporte in dem Testgebiet vornehmen!

Vorgehensweise Testimport und aktueller Stand

Hinweise zu den Themen:

• Engstelle: die meisten der Punktobjekte werden im JOSM-Editor nicht als Icon dargestellt, sind also schlecht zu erkennen.

Datenmengen:

Von 3458 Datensätzen in der Sachdaten-DB sind

3392 Geometrien inkl. Sachdaten in osm-Dateien transformiert worden (5 Objekte ohne Datensätze).

Im Testgebiet sind 527 Geometrien inkl. Sachdaten vorhanden.

Reihenfolge Import	Thema	Anzahl Test (Anzahl Gesamt)	Stand	Bemerkungen
1	Belag	45 (160)	erledigt	letzte Abstimmung mit Uni ausstehend Die Flächen (Themen Belag, Längsneigung und Querneigung) sind manchmal identisch, ungefähr gleich oder teilweise überschneidend und werden vor dem Import miteinander abgeglichen, d.h. kleine Knotenabweichungen werden angepasst und die Flächen ggfs. aufgeteilt, wenn übereinanderliegend im Original GIS. Danach Import. Dabei werden vorab in openstreetmap die vorhandenen Objekte verschoben, weil davon ausgegangen wird, das diese Flächen lagerichtig sind. OFFEN: Mit Uni nochmal Definitionen klären, ob genau deckungsgleich mit uns (Art und Zustand) OFFEN: Zusätzlich zu einer Fläche muß ein offener Weg mit den gleichen Eigenschaften definiert werden bzw. ein vorhandener angepasst werden, damit für das Routing Wege vorhanden sind (Flächenrouting aktuell noch nicht unterstützt von den Routing-Programmen gemäß talk-de Mailinglisten-Diskussion ca. April 2010 wg. Dortmund Flächenerfassungen). OFFEN: Bei ersten Importen wurde bei Flächen für Straßen der Straßenname nicht nochmal bei den Flächenobjekten ergänzt, sondern nur bei dem Weg belassen, sonst wird der Name auch mehrfach gerendert. Evtl. wird es notwendig werden, eine zusätzliche Relation für Wege und Straßen zu definieren, damit mehrfache Flächen für Straßen zusammengefasst werden. Aktuell dürfte es problematisch sein, die Flächen irgendwie zu verwenden, außer der Anzeige. Es müsste fürs Routing eigentlich bei mehreren parallelen Flächen jedesmal noch ein Weg darin eingezeichnet werden ohne Relation, aber auch mit einer Relation würden nur die Flächen zueinander in Beziehung als gemeinsame Defintion für eine Straßenfläche taugen, das Routing wäre immer noch nicht erledigt. (OFFEN: besser formulieren)
1a	Längsneigung	22 (152)	erledigt	mit den anderen Flächen verschnitten und importiert letzte Abstimmung mit Uni ausstehend
1b	Querneigung	26 (220)	erledigt	1 Datensatz vermutlich falsche Richtungsangabe, da falsche Ausrichtung zur dort auch vorhandenen Längsneigungsfläche letzte Abstimmung mit Uni ausstehend
2	Absenkung	174 (1348)	erledigt	Tagung wurde eigenständig definiert
3	Parkhaus	3 (17)	erledigt	abgeglichen, 1 übernommen, von 2 einige Sachdaten übernommen
3a	Parkplatz	4 (17)	erledigt	abgeglichen 3 übernommen
3b	Ruhebank	44 (385)	erledigt	importiert
3c	Taxistand	3 (8)	erledigt	importiert
3d	Telefon	3 (41)	erledigt	2 importiert
3e	WC	4 (9)	erledigt	Drei der Toiletten sind offenbar in Warenhäusern. Es muß in nachhinein geprüft werden, in welchen Gebäude, in welchen Etagen, die Zugänglichkeit und ob eine explizite Nutzungsgenehmigung vorliegt.
4	Ampel	44 (305)	erledigt	evtl. fehlt ein Ampelmast, über FIXME ergänzt bei Überquerungsknoten Import abhängig von Thema Absenkung, weil dort abgesenkte Bordsteine auch an den Fußgängerüberquerungen definiert sind.
12a	Zugangebenerdig	10 (34)	erledigt	Position und Weglänge muss händisch neu erfasst werden (Treppengeometrie Kartendarstellungsorientiert)
12b	ZugangRampe	7 (24)	erledigt	Wege bei Eingängen erstellt und mit FIXME versehen zur entgültigen Ausrichtung
12c	ZugangStufe	3 (10)	erledigt	Wege bei Eingängen erstellt und mit FIXME versehen zur entgültigen Ausrichtung
12d	ZugangTreppe	8 (34)	erledigt	Wege bei Eingängen erstellt und mit FIXME versehen zur entgültigen Ausrichtung
101	Einrichtung	28 (128)	erledigt	nach Import zusätzliche Datenspende öffentliche Einrichtungen blieben nur 2 übrig, die nicht vorhanden waren. Diese wurden importiert.
102	Zugangebenerdig	10 (34)	erledigt	Objekte wurde im Zugangstuere... Objekt ergänzt OSM-Tagging noch nicht fertig, aber evtl. erstmal komplett importieren, da komplizierte Daten und OSM-Regelung lang dauern dürfte
102a	ZugangtuereFluegel	26 (82)	erledigt	Knoten für Eingänge erstellt und mit FIXME versehen zur entgültigen Ausrichtung
102b	ZugangtuereSchieb	2 (16)	erledigt	Knoten für Eingänge erstellt und mit FIXME versehen zur entgültigen Ausrichtung
995	Rinne	9 (11)	unklares OSM-Tagging
996	Engstelle	50 (325)	20 erfasst	Wichtig sind die Vermerke in dieser Datenstruktur. Die Engstellen sollten im nachhinein nochmal begangen werden, um weitere Einzelheiten zu taggen. Die restlich offenen Engstellen werden nach und nach importiert, wenn die zugrundeliegenden Fußwegabschnitte erfasst wurden.
997	Stufe	0 (8)		entfällt, kein Datensatz im Testgebiet
997a	Treppe	11 (52)	9 erfasst	mind. Treppen-Positionen müssen händisch neu erfasst werden, weil Geometriedaten falsch sind (Kartendarstellungsorientiert)
998	Sonstiges Hindernis	0 (2)		entfällt, kein Datensatz im Testgebiet nur 2 Datensätze insgesamt, daher am Ende wg. OSM-Tagging Unklarheit
999	Haltestelle	8 (50) geschätzt, noch nicht transformiert		entfällt, alle Objekte bereits vorhanden und keine zusätzlichen Daten vorhanden. OFFEN: 2 Kommentare sind zu beachten

Probleme beim Testimport

• Flächenthemen haben geringfügige Abweichungen, wenn ihre Flächen sich überlappen. Kleine Korrekturen annehmen, im Zweifel die größere Vereinigungsmenge der Flächen.
• Wenn Flächen aufeinander treffen, sollte die Verkehrsfläche Vorrang haben, also ggfs. eine Fußwegfläche unterbrechen. Grund ist, das meistens der Belag der Verkehrsfläche richtig ist. (beim oberen Graben ein Auftreten gewesen).
• Die Flächen umfassen manchmal mehrere Straßen, auch quer zueinander verlaufend. Solche Flächen auf einzelne Straßen(bereiche) aufteilen (Bereich hinterer Lech, Fläche Belag).
• Ampel-Thema: relativ großer Importaufand je Kreuzung, das liegt aber auch zum größeren Teil daran, daß getrennte Fahrspuren noch nicht in osm vorliegen und das vorab gemacht werden muß inkl. Bus- und Tram-Relationen, die angepasst werden müssen für die geänderte Wegführung. Die vorhandenen Linien für linke und rechte Überquerungsbegrenzungen werden da verwendet, um a) zusätzliche Bordsteinkanten zu definieren barrier=curb und FIXME=Höhe fehlt noch und b) die Überquerungsbreite zu messen. Diese wird am erstellten Überquerungsweg mit width=* erfasst. Die Überquerungsbegrenzungen werden danach gelöscht, also nicht mit importiert. Zur Feststellung der korrekten Ampelsituation je Überquerungsknoten werden die betroffenen Ampel auf beiden Seiten bzgl. übereinstimmender Werte bei Art der Ampel und Blinden-Ton bzw. -Vibration hin kontrolliert. Die eigentlichen Ampelmast-Standorte werden danach in barrier=traffic_crossing_pole geändert.

Gesamtaufwand für alle Ampeln im Testgebiet ca. 5h.

Erweiterung vorhandener und Entwurf neuer OSM Tags

incline erweitern auf Fläche

Es liegen in diesem Projekt flächenhafte Bürgersteige, die teilweise sowohl eine Längs- als auch Querneigung haben (im Quell-GIS auf verschiedenen Layern getrennt voneinander definiert).

Eine zu erfassende Fläche wäre zu definieren als konstant ansteigend in eine oder zwei Richtungen. Die zweite Richtung ist 90 Grad quer zur ersten Richtung.

Bei openstreetmap ist für den ANSTIEG das Tag incline=* verabschiedet.

Bei einer Fläche würde ich die erste Steigung durch den Steigungsgrad in % gemäß Definition im vorhandenen incline-Tag nehmen incline=* und als Steigungsrichtung eine der acht Haupt-Himmelsrichtungen nehmen, also N für (Anstieg Richtung Nord), NE, E (für Ost), etc. Als Tag schlage ich incline:direction=* vor.

Hat die Fläche eine zweite Steigungsrichtung, wird diese durch die Tags sideincline:direction=* und sideincline:direction=* definiert, wobei die sideincline:direction immer 90 Grad links oder rechts zur incline:direction definiert werden muß.

Bei einer Steigung in zwei Richtungen gibt es keine Vorgabe, welche in incline und welche in sideincline definiert wird.

Das umdrehen der Digitalisierrichtung bei Flächen ist irrelevant für diese Tag-Definition, es werden dadurch keine Richtungsdaten verfälscht.

Queranstieg eines Weges

Der Längsanstieg eines Weges wird mit incline=* definiert. Dies ist u.a. auch sinnvoll auf Fußwege anzuwenden, um die Information für Gehbehinderte und Rollstuhlfahrer zu erfassen.

Ein Weg kann auch in der Querrichtung eine Steigung haben. Die Bürgersteigabsenkung für die Zufahrt von PKWs von der Straße zu einem Grundstück kann schon für Rollstuhlfahrer oder langsam vorankommende Rollator-Nutzer erhebliche Probleme bereiten, daher ist auch solche ein Quergefälle wichtig zu erfassen.

Zur möglichst einfachen Nutzung ähnlicher, vorhandener Tags und zur direkten Kontrolle des neuens Tags unter JOSM empfiehle ich für den Queranstieg

incline:left=* und incline:right=*

Damit ist der seitliche Anstieg gemeint analog zum vorhandenen Längsanstieg bei incline=*. Ich empfehle beide Tags, damit der/der Erfasser/in am einfachsten den Anstieg definiert und nicht bei einem nur left-Prefix immer überlegen muß, ob ein positiver oder negativer Wert zu nehmen ist.

Bordsteinkante

Die Bordsteinkante wird im Thema Absenkung definiert. Dieses wird neu getaggt:

barrier=curb height=* x.x(x) Einheit [m]

Die Seite der Bordsteinkante, welche tiefer ist als die andere, wird aktuell nicht definiert. Es könnte die Digitalisierrichtung verwendet werden und dann left:height=* für links Kante hoch definiert werden.

Ampelmast-Position

Der Ampelmast-Standort wird getaggt

barrier=traffic_crossing_pole

Es wird extra _crossing_ verwendet. Hiermit werden allgemein die Masten auf Fußwegen gekennzeichnet, weil sie generell ein Hindernis darstellen, unabhängig davon, ob dort Ampelsignale für Fußgänger und/oder Straßenverkehr vorhanden sind. Für Blinde sind die Masten darüber hinaus natürlich der anzustrebenede Punkt für eine Überquerung, daher sollten die am Mast befindlichen Überquerungshilfen, wie Anforderung Grünphase, Vibrationsknopf und Tonknopf, zu erfassen.

Von den Keys/Values, die bisher am Überquerungsknoten highway=crossing gesetzt wurden, werden am Ampelmast-Standort folgende Zuordnungen gesetzt:

tactile_paving=* wenn ein taktiles Hinweisfeld auf den Ampelmast hinweist. Ist ein taktiler Weg zum Mast vorhanden, wird dies am erfassten Fußweg beschrieben und der Weg führt zum Ampelmast-Standort.

traffic_signals:sound=* und traffic_signals:vibration=* sollten nur dann am Ampelmast-Standort definiert werden, wenn die Buttons nicht für beide Seiten der Überquerung übereinstimmen.

interne Merkposition

• je Export eines Layers vom SchulGIS die Logs prüfen bzgl. unbekannter Geometrie-IDs