Das OpenStreetMap-Datenmodell
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Anzahl der Teile | 31 | |
| Autor | ||
| Lizenz | CC-Namensnennung 3.0 Unported: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. | |
| Identifikatoren | 10.5446/15835 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
3
6
7
12
13
14
16
20
25
26
27
00:00
KoordinatenBitObjekt <Kategorie>SoftwareNegative ZahlEditorMagnetbandlaufwerkGleichmäßige BeschränktheitServerInformationDatenverarbeitungProgrammiererAussage <Mathematik>InformationsspeicherungComputeranimation
01:39
DatenmodellMetadatenObjektklasseMetadatenDatentypFlächentheorieDatenmodellAttributierte GrammatikComputeranimation
02:10
Objekt <Kategorie>MetadatenAttributwertFlächentheoriePolygonGeometrieAttributierte GrammatikVorlesung/Konferenz
02:46
UnicodeMAPPERSoftwareLiniePolygonEditorDatenbankFlächentheorieTyp <Informatik>Mischung <Mathematik>OrdnungsbegriffGleichheitszeichenMachsches PrinzipKlasse <Mathematik>Attributierte GrammatikVolumenvisualisierungObjekt <Kategorie>Weg <Topologie>Gebiet <Mathematik>FlächeRichtungZeichenketteWort <Informatik>ART-NetzFluss <Mathematik>DatentypLeiste <Technik>ZifferComputeranimation
08:52
Klasse <Mathematik>Objekt <Kategorie>Aktion <Informatik>Inhalt <Mathematik>
10:07
World Wide WebDatentypNetzadressePOWER <Computerarchitektur>ZeichenketteYES <Computer>Typ <Informatik>MeterDefaultObjektklasseReverse EngineeringObjekt <Kategorie>MengeKlasse <Mathematik>ParserDatentypGeschwindigkeitTRAMO <Programm>UnterteilungOrdnungsbegriffLogischer SchlussVolumenvisualisierungInformatikZahlSTYLE <Programmierumgebung>DatenbankWort <Informatik>Attributierte GrammatikThreadFluss <Mathematik>Computeranimation
15:07
RichtungZählenMengeComputeranimation
15:35
SimulationYES <Computer>Automat <Automatentheorie>MengeDienst <Informatik>Portal <Internet>Computeranimation
17:01
MetadatenUpdateUpdateMetadatenQuellcodeMengeTabelleComputeranimation
17:44
Mooresches GesetzZoomMaßstabTurbo-CodeComputeranimation
18:09
Vertex <Computergraphik>DatenmodellDatentypPolygonSpitze <Mathematik>DatenbankComputeranimation
19:04
SoftwareFormale BeschreibungDatenmodellUmsetzung <Informatik>YES <Computer>AnwendungssoftwareMAPPERKraftFlächeC++QuellcodeRohdatenEntscheidungstheorieRegelungART-NetzTUNIS <Programm>Große VereinheitlichungFaktorisierungProgrammierspracheZahlenbereichBiproduktAktion <Informatik>Mechanismus-Design-TheorieStatistikVorlesung/Konferenz
Transkript: Deutsch(automatisch erzeugt)
00:00
Ich glaube, den muss ich enttäuschen. Werden wir sehen. Open Stream hat ein ganz einfaches Datenmodell, wissen wir alle. Es gibt Nodes, Ways, Relations und es gibt freie Tags, ihr könnt taggen, was ihr wollt und jetzt sind wir eigentlich fertig, oder? Mehr ist da nicht. So ist das, wie man sich das generell vorstellt. Dann versucht man es mal ein bisschen aufzumalen,
00:21
dann merkt man schon, es ist ein bisschen komplizierter und dann fängt man an, wenn man ein bisschen reinguckt, wenn man irgendwie die Software programmieren will, die OSM-Daten auswertet, dann stellt man sich plötzlich solche Fragen oder stellt sich vielleicht nicht und stolpert dann aber drüber. Ja, maximal 2000 Nodes pro Way zum Beispiel. Das war früher nicht so, das hat sich irgendwann geändert. Das heißt, wenn man historische Daten verarbeitet,
00:41
dann muss man damit rechnen, dass das nicht der Fall ist. Ja, solche Kleinigkeiten. Keys und Ways sind auf 255 Zeichen beschränkt. Zeichen, nicht Bites. Ich habe es nicht ausprobiert, habe es mal irgendjemand ausprobiert. Irgendwo auf einer Wiki-Seite habe ich diese Information gefunden. Ich weiß nicht, ob es stimmt.
01:01
Okay, also auch diese Sachen, diese Sachen können sich ändern. Wer wusste, dass man gelöschte Objekte unter der gleichen ID wiederbeleben kann? Es gibt nur einige Leute, die das wissen. Ja, also solche Dinge kommen vor. Negative IDs werden häufig so im Viosen und anderen Editoren verwendet
01:21
für vorläufige IDs, wenn man vom Server noch keine gekriegt hat. Koordinaten werden nur mit etwa 1 cm Genauigkeit abgelegt. Das ist sehr praktisch passend. In 8-Bytes kann man also 2-4-Bytes-Integers angeben. Hat man schon mal die Hälfte gespart gegenüber einem Double, wenn man diese Daten speichern will. Solche Dinge werden plötzlich interessant, wenn man eben Milliarden von Notes verarbeiten will.
01:42
So, also Open-Street-Map-Datenmodell ist komplexer als man denkt. Und ich will jetzt so ein paar Sachen mal durchgehen, so ein paar Beispiele und ein paar Sachen, was man so entdeckt und was man sehen kann. Ich hatte eigentlich ursprünglich gedacht, ich mache hier irgendwie so einen systematischen Übersicht und gucke ganz genau an, was es im Open-Street-Map-Datenmodell alles gibt, aber dafür hätte ich den ganzen Tag gebraucht.
02:01
Das heißt, ich ziehe mal so ein paar Sachen raus, die immer wieder vorkommen oder die immer mal wieder Probleme verursachen. Falsche Flächen, Objektklassen und Attribute, Datentypen, das magische Semikolon und die Metadaten. Wenn man so aus der Gießwelt kommt, dann denkt man eigentlich noch, ich habe irgendwie Objekte, Punkte, Linien, Polygone, die geben irgendwie meine Geometrie an
02:21
und dann habe ich irgendwie Attribute dazu. Bei Open-Street-Map haben wir die Objekte, die geben mir die Geometrie an, geben mir die Tags und die Semantik. Das wäre ja so schön, aber so ist es eigentlich nicht. In Wirklichkeit ist es etwas kompliziert. Ich habe Nodes, Punkte, das stimmt noch ganz gut. Welche Linien stimmt schon nicht ganz, weil manchmal können das ja schon Flächen sein. Weiß man nicht so richtig. Relationen können alle möglichen sehr komplizierten Objekte darstellen.
02:42
Das heißt, wenn man so eine Relation vor sich hat, dann muss man erstmal ganz genau in die Tags reingucken um festzustellen, was das eigentlich ist und wie man das vielleicht verarbeiten möchte. Flächen. Wie viele Möglichkeiten gibt es, flächenhafte Objekte in Open-Street-Map darzustellen? Klar, der erste Weg ist relativ einfach, wenn ich einen geschlossenen Weg habe.
03:01
Der Endpunkt des Weges ist wieder der Anfangspunkt. Dann kann das eine Fläche sein. Es muss aber keine Fläche sein. Wenn er ja gleich jetzt dran ist, dann ist es schon wahrscheinlicher, dass es eine Fläche ist. Wenn er gleich jetzt dran ist, an einem offenen Weg, weiß wieder keiner, was er damit machen soll. Was ist ein Roundabout, der eine Grünfläche drin hat? Der Roundabout ist ein linienhafter Weg.
03:23
Das ist die Straße, Highway, irgendwas. Und die Grünfläche selber, Landuse, also das Ding ist mit Landuse und Highway getaggt, dann ist das eine Objekt beides. Es ist sowohl eine Linie als auch ein Polygon. Und damit muss man umgehen können unter Umständen. Das ist sowas, wo ein ID-Editor oder sowas natürlich Schwierigkeiten hat, sowas richtig darstellen zu können im Editor.
03:42
Und das kommt vor. Das ist nicht irgendwie jetzt ausgedacht, sondern ich habe jetzt gerade mal nachgeguckt in der Datenbank. Es gibt 3.000 Mal in der Datenbank diese Kombination, ein Objekt, was sowohl Highway als auch Landuse getaggt ist. Nur so mal als Beispiel. Die andere Möglichkeit, wie man Polygon darstellen kann, ist mit Multipolygon-Relationen.
04:01
Das sind also solche, die Type Multipolygon haben oder Type Boundary. Boundary gibt ja eigentlich auch die Grenze eines Landes an oder eines administrativen Gebietes. Und eigentlich ist das ja auch ein Polygon. Das administrative Gebiet ist ein Polygon. Wird aber mit diesem anderen Type. Manche machen es so, manche machen es so. Benutzen wir für große Flächen. Da wo ein einzelner Way uns nicht mehr ausreicht,
04:22
benutzen wir für Flächen mit Löchern. Das können wir mit den einzelnen Ways nicht machen. Benutzen wir für Multipolygon. Das heißt, wenn ich mehrere äußere Ringe haben möchte, sagen möchte, diese Inselgruppe, der möchte einen gemeinsamen Namen geben oder was auch immer, dann müsste ich das so machen. Die Frage ist immer natürlich, welche Tags gelten jetzt. Mache ich die Tags an die Relation oder an die Ways oder inneren und äußeren und so.
04:41
Da gibt es verschiedene Schulen, verschiedene Leute, die verschiedene Ideen haben, verschiedene Software, die verschiedene Ideen haben. Das heißt, man muss davon ausgehen, dass wenn man eine andere Software verwendet als MAPNIC und OSM2PQ SQL, dass es dann unter Umständen anders rauskommt als auf der Standardkarte. Und das wissen wir alle, das ist ja was gilt. Wir mappen ja immer für ein Renderer. Wir mappen immer für das, was auf der Standardkarte drauf ist.
05:01
Das ist das, was stimmt. Alles andere spielt eigentlich keine Rolle. Es gibt auch noch mehr Möglichkeiten, wie man Flächen darstellen kann. Zum Beispiel Flussflächen. Früher war das mal so. Man hat sich vielleicht schon mal der eine oder andere gefragt, warum haben wir einen Tag, das heißt Waterway Riverbank. Das liegt da, dass wir ursprünglich gesagt haben, okay, wir haben hier das Flussufer und entlang des Flussufers ziehen wir einen Weg.
05:21
Und dann, wo der aufhört, dann hören wir dann irgendwann auf und setzen den nächsten dran, dann setzen wir den nächsten dran, so wie wir das in der Küstenlinie machen. Dann hat man aber festgestellt, ja, das ist aber schwierig zu zeichnen, weil das ist ja dann einzelne Wege, die müssen wir erst zusammensetzen, das ist zu viel Arbeit. Das heißt, wir sagen im Editor, schließen wir jetzt diese Riverbank-Linien zu Flächen und haben also hier ein Stück Fluss
05:41
und dann kommt noch ein Stück Fluss dran und dann kommt noch ein Stück Fluss dran und alles zusammen wird dann nachher blau eingefärbt und dann passt das schon. Also für einen Renderer ist das ja auch in Ordnung. Macht auch nichts, wenn die Flächen sich so ein bisschen überlappen. Das hat man auch lange Zeit so gemacht. Und wenn da ein Inselnfluss ist, auch ganz praktisch, dann tut man an der Stelle aufteilen, kann man rausnehmen. Wunderbar. Also so hat man das auch eine ganze Weile lang gemacht.
06:01
Heutzutage sind ein paar andere Tags, die die Leute angefangen haben zu mappen. Und es gibt so eine ganz interessante Mischung aus verschiedenen Möglichkeiten, wie man einen Fluss eintragen kann. Und auch da gilt wieder, letztlich das, was der Mapnik-Renderer macht, das gilt und wenn irgendjemand anders was anderes macht, dann hat er unter Umständen Pech gehabt und die Sachen kommen nicht richtig raus.
06:22
Klammer auf, auch beim Mapnik kommen die Sachen nicht immer richtig raus. Kann schon mal sein, dass irgendwelche Inseln plötzlich unter Wasser sind oder so. Also wieder eine Möglichkeit, wie man Flächen darstellen kann. Und wir haben noch diesen Spezialfahnen mit den Küstenlinien. Auch da haben wir eigentlich die Landflächen oder die Wasserflächen beschreiben wir durch diese Küstenlinien, die wir auf spezielle Art und Weise zusammensetzen,
06:42
was immer wieder zu Problemen führt. Das heißt, wir haben mehrere Möglichkeiten, letztlich mit dem Gleichen umzugehen. Und das kann so nicht weitergehen. Wir brauchen irgendwann einen echten Area-Datentyp. Mal eine Umfrage, wer stimmt mir zu, wer ist dafür, dass wir einen Area-Datentyp einführen?
07:04
Andersrum, wer ist dagegen? Da hinten traut sich jemand. Okay, gut. Die Frage ist natürlich noch, wie wir das machen. Wie das genau zu machen ist. Da sind sehr, sehr viele Schwierigkeiten dabei. Will ich jetzt nicht darauf eingehen. Geometrien, Thema mal X.
07:22
Jetzt gucken wir uns an, wie das eigentlich mit den Tags ist. Tags bestehen immer aus diesen beiden Teilen, dem Key und dem Value, typischerweise durch ein Gleichheitszeichen getrennt. Das muss aber nicht immer so sein. Und natürlich kann man auch Gleichheitszeichen in die Keys oder Values reintun und dann wird das besonders schön. Fast beliebige Unicode-Zeichen. Es gibt ein paar Unicode-Control-Characters,
07:41
die man in XML nicht benutzen darf, die dürfen wir auch nicht benutzen. Aber sonst können wir alles haben. 255 Zeichen. Was steht denn jetzt da eigentlich drin? Wir haben sehr häufig so eine Aufteilung, die so ein bisschen halb in unseren Köpfen existiert, dass wir die Welt aufteilen in Klassen von Objekten, die dann zusätzliche Attribute haben.
08:00
Also wir haben irgendwie gesagt, Straßen, das ist eine Straße. Das ist nicht irgendwas anderes. Das ist eine Straße, die hat jetzt zusätzliche Informationen, die heißt Schillerstraße und das ist eine Einbahnstraße. Dieses Denken kommt häufig aus dieser sonstigen GISS-Welt, wo man ja auch Layer hat. Jede Klasse von Objekten ist in einem Layer drin. Und zusätzliche Attribute, die festgelegt sind.
08:21
Das haben wir bei OpenStreetMap aber eigentlich nicht. Bei OpenStreetMap gibt es keine Unterscheidung zwischen diesen Klassen und den Attributen. Das merkt man dran, wenn man plötzlich sowas hat hier. Ja, das kommt vor. Das ist also ein Weg, der ist sowohl eine Straße als auch eine Eisenbahn. Und jetzt stellt sich die Frage, für was gilt eigentlich dieses One-Way? Und für was gilt der Name?
08:42
Für Menschen ganz einfach. Der Mapper guckt an. Offensichtlich die Schillerstraße, die Eisenbahn. Die Straßenbahn wird ja wohl nicht Schillerstraße heißen. Aber für einen Computer wieder etwas schwierig zu erkennen. Und One-Way, naja, es könnte ja auch sein, dass die Straßenbahn nur in einer Richtung fährt. Das führt dann zu Problemen. Wir hatten zum Beispiel mal eine Aktion, da hat jemand gesagt, McDonalds schreibt sich so, wie ich es hier gemacht habe.
09:01
Ich habe es extra nachgeschaut. Kein A nach dem großen M und Apostroph und so weiter. Und er korrigiert mal alle Objekte, die irgendwie den Namen McDonalds haben und anders geschrieben sind, weil das sind ja offensichtlich alles McDonalds. Und da sind halt so ein paar Sachen schief gelaufen. Ich weiß nicht genau, was er genau gecheckt hat, aber die Frage ist jetzt, wie finde ich denn
09:20
überhaupt alle McDonalds. Dann gehe ich dann nach, ob da zusätzlich ein Tag Amenity Restaurant dran ist. Oder muss Amenity Fast Food sein? Oder Fast Food Yes? Oder noch irgendwas anderes? Und was ist, wenn da irgendwie, ich weiß nicht, in Schottland gibt es vielleicht einen Pub, der McDonalds heißt oder so, der sich aber anders schreibt und der kein Franchise von dieser bekannten
09:42
Firma mit dem M ist. Es ist sehr schwierig rauszukriegen anhand dieser Tags und dieser Kombination, was denn jetzt irgendwie alles wirklich zu irgendeiner Klasse gehört. Natürlich kann man auch einfach alle diese Objekte in eine Relation reintun und dann hat man wieder seine Sammlung. Und ich sehe schon,
10:00
die Reaktion wollte ich sehen von einigen Leuten, die den Kopf schütteln. Also auch nicht unbedingt die richtige Lösung. Und das wird immer schlimmer. Also zum Beispiel diese Tags findet man zu tausenden, aber tausender Datenbank. Type Broadleaf, das kann man nur
10:21
interpretieren, wenn man weiß, dass das zu Natural Tree gehört. Type Water ist wahrscheinlich, ich weiß gar nicht, woher es gehört. Ich nehme an, es kommt zum Power Generator, also Wasserkraftwerke, Type Lake. Da gibt es auch verschiedene Varianten. Es gibt noch lauter andere Sachen von Types. Also solche allgemeinen Tags sind sehr, sehr problematisch, weil man nicht weiß, wo das irgendwie dazu gehört. Also wenn ich eben
10:41
mehrere Sachen habe, was ist es denn jetzt? Also es gibt keine verlässliche Unterscheidung zwischen diesen Objektklassen und den Zusatzattributen. Man muss irgendwie sich das so dynamisch zusammensetzen anhand der Kombination von Tags erraten, was möglicherweise gemeint sein könnte. Und das kann sich ändern, wenn die Leute neue Tags erfinden. Kann es sein, dass die alten Tags neu interpretieren müssen anhand dieser neuen Daten.
11:02
Und das ist natürlich schwierig, weil wir wissen ja nicht, ob irgendwas schon aktualisiert wurde oder nicht unbedingt. Natürlich lassen sich Objekte dieser Welt nicht in Klassen aufteilen sowieso. Trotzdem versuchen wir es immer wieder. Also unbewusst denken wir häufig in dieser Unterteilung Klassenattribute, die aber nicht so richtig passt. Aber die Renderer denken eben auch häufig so. Typischerweise, ich habe
11:20
irgendwie eine SQL Query. Da gebe ich mir alle Objekte, die in Highways sind. Und dann habe ich eine Liste, welche Styles ich genau haben möchte dazu. Das ist genau wieder dieser Klassenwertsattribut Geschichte. So ein bisschen kann man da vielleicht was machen mit dem Doppelpunkt. Das hat schon eine sehr lange Historie, dass wir den Doppelpunkt so als hierarchisches Trennzeichen einführen. Und dass wir eben sagen, zum Beispiel alle Sachen, die
11:40
jetzt zu einer Adresse gehören. Wir haben also andere Doppelpunkt Street, um zu sagen, dass ist der Straßenname, der jetzt zu der Adresse gehört. Das ist nicht ein Straßenname, der zu irgendwie was anderem gehört. Oder dass man eben sowas sagen kann, wie Max Speed, HGV. Also für Heavy Goods Vehicle, also für Lastwagen, gilt da eine andere Geschwindigkeit. Wir ordnen
12:01
die Sachen also ein bisschen verschiedenen Oberklassen, Unterklassen zu. Es gibt verschiedene Möglichkeiten, wo man das machen kann. Und vielleicht ist das auch was, was wir mehr haben müssten. Ich hatte vorhin das Beispiel One Way, kürzester Tram oder zum Highway. Vielleicht müssten wir Highway One Way schreiben, um zu sagen, auf was sich da irgendwas bezieht. Und vielleicht müssten wir auch
12:20
Highway Name und Bridge Name, sodass wir unterscheiden können, was wir heute nicht können. Wenn ich eine Brücke habe und da habe ich einen Namen dran, ist immer wieder die Frage, ist das der Name der Straße, die über die Brücke führt, oder ist das der Name der Brücke? Nächste Frage. Ich habe diese Tags
12:40
und die haben alle eben diese Form Key Value und das können beliebige Strings sein. Wenn ich es verarbeiten möchte und sortieren möchte zum Beispiel, dann muss ich aber wissen, was habe ich da für einen Datentyp? Ich kann sortieren, dann habe ich die, habe ich alle Sachen immer schön lexikalisch irgendwie sortiert und das ist ja für die Goethe-Straße nett. Aber für die Hausnummern macht das vielleicht keinen Sinn.
13:01
Die möchte ich vielleicht nach Größe sortieren oder sowas. Das heißt, ich muss mir angucken, was für einen Datentyp hat mein Value eigentlich? Da haben wir verschiedene Beispiele. Goethe-Straße, okay, ist eine Zeichenkette, würde jetzt der Informatiker sagen, oder ein String. Bei Area gibt es Yes und No sozusagen. Es gibt auch True, One und so weiter. Letztlich fällt das alles auf den Bullionwert zurück.
13:21
Es gibt Ja oder Nein. Wir haben Aufzählung. Highway gibt es ungefähr 20 verschiedene Typen. Von der Autobahn runter bis zu irgendwie dem Fußweg. Letztlich muss man wissen, welche Typen es gibt und welche Typen zugelassen sind. Alles andere kann man ignorieren oder kann man irgendeinem Default
13:41
zuweisen. One Way ist kein Bullion übrigens. Es gibt One Way minus 1 Tag. Hab ich nachher noch, bin ich noch da? Hab ich nachher noch eine Folie zu. Dann haben wir solche Sachen Width zum Beispiel, also die Breite eines Schlusses oder sowas kann man damit angeben.
14:03
Da hat man eine Zahl und dann hat man eine Einheit dazu. Und wenn die Einheit nicht angegeben ist, dann sind Meter Default normalerweise. Aber das können auch Feet oder irgendwas anderes sein. Bei Hausnummern, da haben wir schon wieder etwas komplizierteres. Beim Rev gibt es dann solche Sachen.
14:21
Also dass man sagen kann, das ist die A5 und die A3, die ist da beide auf der gleichen Autobahn zusammen. Also das ist eigentlich eine Menge von mehreren Zeichenketten, die wir haben. Oder vielleicht einen Array oder sowas. Informatisch überreden. Aber es gibt noch viel, viel kompliziertere Dinge. Und es werden immer mehr Leute, die diese komplizierteren Dinge
14:41
sich immer mehr ausdenken und da tolle Sachen mitmachen. Also zum Beispiel die Opening Hours. Da gibt es sehr, sehr komplizierte Regeln, wie man die genau so bauen hat. Und ich möchte keinen Parser dafür schreiben für viele von diesen Dingern, weil viele von diesen Dingern sich irgendjemand ausgedacht hat, der keine Ahnung davon hat, wie man solche Sachen parsen muss, sondern nur irgendwie macht so, dass es für Menschen verständlich ist.
15:02
Also wir brauchen diese Unterscheidung, aber wir müssen verstehen, wie diese Datentypen sind, weil wir es validieren wollen, weil wir performant verarbeiten wollen. Und hier ist also so ein Beispiel mit den Oneways. Also es gibt Yes, No, Minus 1. Minus 1 heißt, es geht in die andere Richtung, als der Way zeigt. Und so weiter. Also da ist eine ganze Menge
15:21
mehr mit dabei. Semicolons. Hier, das ist das Beispiel, wie man Semicolons verwendet. Und einer der wenigen Karten, die das auch macht, das ist die MapQuest-Karte. Wenn da also I70, Semicolon US40 steht, dann nimmt ihr es auseinander. Das geht aber nur, wenn es irgendwie nur zwei Werte sind. Wenn es mehr werden, dann geht es auch wieder nicht mehr. Es gibt solche Fälle, am Ende die Bank-ATM, wenn ich also eine Bank habe mit Automat.
15:43
Sollte man, man sieht häufig, inzwischen häufiger mehr das zweite. Aber es ist nicht einfach nur eine Menge. Es ist etwas unklar, was damit gemeint ist. Man kann nicht sagen, Semicolon ist immer eine Menge von verschiedenen Sachen. Also im ersten Fall zum Beispiel die Boje, die hat drei Streifen, rot, grün und rot.
16:00
Die kann man nicht durcheinanderschmeißen oder irgendwie sowas. Dieses Census Population sagt offensichtlich, in 2006 gab es da 107 Leute. Das ist auch nicht eine Menge, die man beliebig durcheinanderschmeißen kann. Und dann hat man dann furchtbar solche Source-Angaben, wo es dann furchtbar schief geht, wenn man die aggregiert. Das Schlimmste sind die Betoren. Josemann, eigentlich macht es jetzt auch so,
16:22
wenn ich eine Straße habe, die residential ist und eine die service ist und verbindet sie zu einer Straße, dann ist der Default, dass die hinter residential Semicolon service ist und das bringt einem überhaupt nichts. Und besonders schön, wenn man one way yes no und das hat man ja zu größeren Mengen da. Also es gibt dann yes no und no yes und yes Semicolon Leerzeichen no und es gibt
16:41
yes no minus 1. Also und es gibt 58.000 Water Lake Pond. Das muss irgendein Import gewesen sein. Was soll ich denn mit so einer Angabe anfangen? Also diese Semicolon lieber gar nicht verwenden. Der redet nicht über OSM.
17:04
So Metadaten. Jetzt wird es noch schwieriger. Source, also die Quelle, die ich in irgendeinem Tag speichere, die Quelle, wo ich irgendwelche Daten herhabe, das habe ich jetzt in dem Tag drin. Das ist eigentlich Daten über meine Daten. Ich möchte vielleicht auch noch speichern,
17:21
die Zuverlässigkeit der Daten letzte Update, von wann bis wann die gültig waren. Und eigentlich hätte ich da gerne so eine Tabelle. Ich möchte für jeden einzelnen Tag festlegen, wo er herkommt und wie zuverlässig er ist. Und die Aktualität ist ganz abgesennt davon, dass es eigentlich die Menge von mehreren Tags ja schon eine Bedeutung hat. Das geht eigentlich so gar nicht. Da habe ich noch den Zeitraum. Ich möchte gerne sagen, das Gebäude stand da mal vor 100
17:40
Jahren. Das ist eigentlich eine andere Achse. Das kann ich mit den Tags so eigentlich gar nicht unterbringen. Dann habe ich das Problem, für welchen Datenmaßstab erfassen wir die Daten eigentlich? Diese schönen Detailkarten sehen alles super aus. Wenn man die, was wir vorhin gesehen haben, diese Topokarte anguckt zum Beispiel. Aber ehrlich gesagt, also die kleinen Zoomlevel, die sehen scheiße
18:00
aus, oder? Auf unserer normalen Karte. Dafür haben wir die Daten nicht erfasst und deswegen passt sie nicht. Darüber müssen wir auch nachdenken, wie wir diese Daten besonders erfassen können, damit wir damit arbeiten können. Gut, also wir wollen Polygondatentyp. Kann ich jetzt sagen, weil die Mehrheit hier dafür gestimmt hat und nicht dagegen. Müssen wir uns überlegen, vielleicht
18:21
noch andere Spezialdatentypen. Hier reiche Keys. Wollen wir sowas? Wollen wir irgendwelche Datentypen für Tags einführen? Zumindest mal dokumentieren, was das vielleicht sein könnte. Das heißt ja nicht gleich, dass wir es in der Datenbank auch so umsetzen müssen. Brauchen wir strukturierte Versionen für die Öffnungszeiten? Möchte ich da vielleicht so eine ganze Jason-Struktur dranhängen können oder irgendwie sowas?
18:41
Letztlich ist die Frage, wollen wir mit diesem simplistischen Datenmodell weitermachen, was wir jetzt haben? Und dann verzichten auf all diese komplizierten Sachen, die wir letztlich nur mit dem komplexen Datenmodell umsetzen können, meine ich. Oder wollen wir mehr ausdrücken? So ein bisschen wollen wir selbst beschränken, wollen wir sagen, naja, OSM ist halt für eine typische Straßenkarte gut, aber 3D,
19:01
naja, kann man so ein bisschen machen, aber so richtig eben doch nicht. Oder wollen wir diese Offenheit weiter haben und jetzt bin ich durch. Danke schön.
19:21
Also,
19:50
vielleicht nicht so sehr erstmal eine Frage, aber eine Anmerkung zu vorhin. Also, ich habe es mal nachgeschaut, Highway Roundabout mit Lentius gibt es gar nicht, so wie ich das gefunden habe. Aber es gibt tatsächlich
20:02
wohl eine legitime Verwendung, nämlich die ich legitim empfinden würde, Highway Pedestrian plus Lentius Village Green oder Lentius Plaza, wo ich sagen würde, mit Ägypten einen gewissen Sinn. Ansofern, vielleicht soll man sagen, auch in solchen Fällen, wo es völlig abwegig ist, dann vielleicht schon noch sinnvolle Nutzungsfälle. Aber zu einer Berührung, die Falschen überwiegen. Also, es gibt irgendwie, das
20:21
meiste ist Highway Residential Lentius Industrial. Was auch immer die Menschen sich dabei gedacht haben. Also, ich meine, es ist keine Frage, dass es sinnvolle Anwendungen dafür gibt. Das Problem ist, dass viele von diesen Sachen, wenn ich die Daten auswertig dran denke, dass es da all diese extra Tricks gibt und dass ich diese Sachen berücksichtigen muss.
20:41
Und es sehr gut sein kann, dass ich zum Beispiel sage, naja, das muss ja irgendwie eine Fläche sein, weil es ist ja irgendwie geschlossen und es hat einen Lentius Tag, aber da ist noch dieser Highway Tag, mit dem ich nichts anfangen kann, den ich dann vielleicht in meiner Software übersehe oder sowas. Also, das Problem ist, also ich meine, klar, wir haben ein Problem, dass viele von den Daten Unsinn sind, die wir bei OSM drin haben, aber die meisten Daten sind
21:00
in Ordnung und die sind völlig sinnvoll eigentlich, aber kaum auszuwerten automatisch, weil wir nicht so richtig wissen, was da überhaupt dran ist. Ja, da stimme ich voll zu. Dankeschön, wenigstens einer. Ihr dürft, also ihr braucht nicht Fragen stellen, ihr dürft doch lästern, wenn ihr wollt.
21:22
Wenn euch irgendwas nicht gefallen habt. Auch nicht? Peter, Peter will lästern. Klar will ich lästern. Nein, ich wollte einen Vorschlag anbringen, und zwar, es gibt zwei, nein, es gibt zwei Probleme. Das eine ist, dass diese... Nur zwei,
21:41
dann ist er okay. Für die ich eine Lösungsidee hätte. Das eine ist, ja, wir haben so ein komisches Datenmodell. Okay, ja, nehme ich mal hin. Das andere ist, jede Anwendung wertet es anders aus. Und zumindest für den Teil könnte man eine Lösung bieten. Ich meine, zu sagen, okay, wir wissen um unsere komischen Regeln mit dem One-Way und dem Minus-1,
22:02
das muss man nur irgendwo hinterlegen in Form einer Library, in Form einer Definitionsdatei, in Form von irgendwas, wo man diese Regeln einfach mal festlegt, als nicht wie ich hier als Text beschrieben, sondern so, dass ich das in der Anwendung auch konsistent auswerten kann, dass der eine Importer das macht wie der andere, wie das Statistiktool. Und ich jag einfach meine Rohdaten da durch und kriege hinterher zumindest ein Subset davon,
22:22
auf das ich mich halbwegs verlassen kann. Denkst du denn, dass sowas möglich ist, oder sind wir da schon über den Point of No Return hinaus und wir haben so viel Mist, dass das gar nicht mehr möglich wäre? Also die Lösung für dein Problem macht zwei neue Probleme. Das eine ist, wer entscheidet, was in dieser Library drin ist. Wir haben keinen Mechanismus, um diese
22:41
Entscheidungen zu treffen. Bisher ist es so, jeder trägt die Daten ein, die er halt will und jeder schreibt ins Wiki, was er halt will und so weiter. Und das Ganze ist dadurch so ein bisschen verteilt, sag ich mal, die Verantwortung und die Entscheidung ist verteilt, weil die Leute, naja, wenn die Leute halt meinen, dass irgendwas gut ist, zu taggen, dann taggen sie es so. Aber es ist
23:01
nicht so, dass ein paar ganz wenige Leute entscheiden, was in so eine Library reinkommt und wie bestimmte Sachen zu interpretieren sind. Das heißt, ja, ich fände es gut, wenn wir da mehr Regeln hätten und ich glaube, wir brauchen das. Aber was wir dazu brauchen, ist ein Weg, wie wir zu solchen Regelungen kommen. Das heißt, wir brauchen in der Community Entscheidungswege, wie wir dazu kommen. Das ist das eine Problem. Das andere Problem
23:21
ist, wie formuliere ich diese Sachen? Ja, eine Library wäre ja nett, aber in welcher Sprache und wie genau und wer kann die dann verwenden und ist das Performant genug und so weiter? Das ist nicht so einfach. Klar, man könnte sich irgendeine Sprache überlegen und sagen, das ist ja nur eine formale Beschreibung und dann muss jeder selber gucken, wie er das umsetzt.
23:41
Diese formalen Beschreibungen tendieren dann dazu, immer und immer komplexer zu werden, bis die Sprache nicht mehr ausreicht, in der sie formuliert sind und dann landet man irgendwann doch bei einer Turing-compliten Programmiersprache, aber das ist halt das andere Problem, dass diese Umsetzung nicht ganz einfach ist. Aber ich sag mal so, der erste Schritt wäre ja schon mal, wenn wir das dokumentieren, ja, wenn wir ganz klar sagen,
24:03
was weiß ich, Bridge, da darf eben nur Yes stehen und nichts anderes oder was auch immer. Das ist ein blödes Beispiel jetzt, aber irgendwie sowas. Da hinten ist eine... Nur als Anmerkung vielleicht, das was OSM2P GSQL
24:21
macht, also sprich das, was auf der Karte landet letztendlich, hat ja schon diese normative Kraft, auch heute schon. Ja, ist das gut? Wer findet das gut? Gut mag das nicht sein. Wer findet das nicht gut? Wer ist gegen Mappen für ein Rendernal?
24:42
Ein paar heben die Hand und ein paar wissen gar nicht mehr, worum es geht. Ja, natürlich, das ist so, de facto ist es so, wir haben wirklich hier so die normative Kraft des Faktischen. Das, was auf der Karte erscheint, ist das, was stimmt. Und das führt dazu, dass alle anderen Leute, die andere Software schreiben, die andere Style Regeln haben, die irgendwie versuchen,
25:01
mehr aus den OSM-Daten rauszuholen, als das, was die Standardkarte produziert, die haben alle ein Problem. Sie haben in Ihrem Bereich, wo Sie irgendwas haben, was sonst niemand hat, da haben Sie die Deutungshoheit, da können Sie sagen, ÖPNV, das mach ich, alle anderen, es interessiert mich nicht, was die machen, weil ich bin die einzige ÖPNV-Karte
25:20
oder Wanderkarte oder Skifahrkarte oder was auch immer das ist. Aber für den allgemeinen Teil müssen Sie letztlich genau das gleiche machen, was die Standardkarte macht und sonst haben Sie verloren. Und das ist manchmal nicht ganz einfach rauszufinden, in tausenden von Zeilen von Map-Next-Style-Files und tausenden von Zeilen von C++ oder was weiß ich, Source Code,
25:40
dem OSM zu PGL und so, rauszukriegen. Was ist es denn eigentlich, was andere Leute implementiert haben und wie kann ich das umsetzen?