Gehling Marc schrieb:
Jede relationale Datenbank hat dafür ein Primary Key und ein Foreign Key mit
Constrains-Konzepte usw. Das müsste man auf OSM transformieren.
Die Relation wird über die Adresse aufgebaut, da diese einzigartig
ist. Natürlich könnte man es auch über die OSM-ID des Gebäudes
oder des Nodes machen, was die Synchronisierung vereinfachen sollte.
wobei ich die nonsql Datenbanken für unsere Zwecke besser finde
Ja, wir haben bereits mit NoSQL-Datenbanken experimentiert.
Funktioniert super, wenn keine Geometrien benötigt werden. Das wird
derzeit alles noch entwickelt und ist leider sehr, sehr langsam.
Vorteil ist jedoch, dass man Indizes auf Values UND Keys legen kann.
Wir verwenden derzeit hstore in PostgreSQL. Wir können so die
Kombination aus Values & Tagss einem Eintrag zuordnen. Nachteil ist
jedoch, dass man den Index nur auf die Keys und die Geometrie legen
kann.
Ich habe vor ewigen Zeiten mal eine Art "Branchenbuch" für OSM
angedacht, die Uni Bonn/Heidelberg hat im Rahmen von OpenLS
dazu eine Infrastruktur aufgebaut, die bereits funktioniert. Problem
ist halt, dass die OSM-Leute alle Daten in OSM führen wollen.
was ja nicht dagegen spricht. Die Daten können ja in OSM stehen.
Somit hättest Du wieder das Ausgangsproblem, wie man sie in OSM
speichert. Relation wären natürlich naheliegend, aber JOSM ist
in meinen Augen ziemlich ungeeignet dafür.
Sinnvoll wäre vielleicht, eine Art "graphischem Relationseditor"
in JOSM zu haben, wo man die Queransicht einen Hauses hat und dann
dort einträgt, in welcher Etage was ist.
_______________________________________________
Dortmund mailing list
[email protected]
http://lists.openstreetmap.de/mailman/listinfo/dortmund
