Meiner Meinung nach wäre die einzig sinnvolle Lösung auf seiten der API. Die API müsste automatisch alle Objekte innerhalb eines Area-Polygons einer Area-Relation hinzufügen… Areas müssten sozusagen wie Relationen funktioneren, in denen alle Objekte innerhalb der Area automatsich Mitglied sind…
Das ist doch mein reden seit Spätherbst 73! 
Damit ist doch das schlaue Polygon gemeint. Du sagst dem Poly was es mit dem darin befindlichen zu schaffen hat und wendet das dann darauf an. Du sagst ihm z.B. das es Sperrgebiet bzw. “Danger Area” ist und was für Beschränkungen gelten und schon gilt das für alles, was sich darin befindet. Kein splitten, kein vergeben von Werten für jedes einzlene Objekt. Ebenso kannst du Ausnahmen machen. Zum Beispiel mal so ins blaue role=ignore für Way xyz. Der läuft dann normal mit seiner Bstimmung durch, links und rechts gelten die Regeln des Gebietes.
Die Begründung gegen das Polygon, weil man es bei größerer Zoomstufe nicht mehr sehen würde, halte ich für hereigeholt. Selbiges Problem gibt es doch für andere Sachen auch: Staaten, Länder, Regierungsbezirke, Kreise, Orte, Wälder, Seen usw. Wenn ich eine bewaldete Insel habe, die im See liegt und nur auf die Insel zoome, dann muß ich auch das große unterliegende Polygon See berücksichtigen, denn ansonsten würde da ja ein Waldstück in der Landschaft raus. Und wir sind uns sicher einig, daß nicht jedes Element mit der kompletten Hierarchie getagged werden soll (Planet=Erde, Kontinent=Europa, Land=Deutschland, …), oder? Diese Sache, daß ein “intelligentes” Polygon Eigenschaften auf alle innenliegenden Elemente vererbt, finde ich auch nicht so attraktiv. Denn dieses würde ja immer eine vollständige Inklusion verlangen und was ist mit den verschiedenen Ebenen? Würde die Vererbung immer auf alle Ebenen wirken oder nur auf einzelne usw.? Ok, lässt sich auch lösen… Aber wie hier schon gesagt wurde: Immer alle Elemente zu zerlegen und individuell mit allen (redundanten) Parametern zu versehen ist nicht nur “komisch” sondern auch sehr fehlerträchtig. Die Wahrscheinlichkeit, bei Änderungen (oder beim Einpflegen) etwas zu vergessen oder zu verfälschen ist groß.
Ebenen sagen dem Render nur was über oder unter wem liegt. Also zeichne die Brücke mit Layer 1 über den Fluss mit 0 oder garnix. Das ist also nur eine Orientierung für die grafische Aufbereitung, hat ansonsten keine weitere technische Funktion. Innerhalb eines “schlauen Polys” wäre alles erfasst, auch Ebenen und Ringelsöckchen mit Klingelglöckchen. Außer du schreibst ihm Ausnahmen vor.
Das geht solange gut bis es ins Detail geht. Wenn man anfängt lückenlose Landuses zu vergeben, mit darin liegenden anderen Landuses, Überschneidungen und Mischnutzungen oder eben auch so komplexe Sachen wie die Adressen, gehen die Probleme los. Relationen sind dazu nur bedingt geeignet. Da muss noch etwas flexibleres her, was nach Möglichkeit auch einiges vereinfacht.
Ich sehe die normalen Relationen auch nciht als Lösung … Das ganze müsste wie schon gesagt auf API-Seite passieren… Also, dass die API beim Abrufen der Daten nicht nur Ways, Nodes und Relations übermittelt, sondern auch informationen darüber in welchen Areas der Objekte liegen… Nur so wäre es möglich den Aufwand für Editoren und besonders für die Renderer möglichst gering zu halten…
D.h. dann, dass bei der Abfrage fuer jedes Element die komplette Datenbank durchsucht werden muss, innerhalb welcher anderen Objekte diese Element liegt. Das scheint mir nicht wirklich praktikabel. Ein anderer Vorschlag war, dass bei dem Element dann eben gespeichert werden soll, innerhalb welcher Objekte es sich befindet. Moeglichkeit 1: Das muss haendisch gepflegt werden. Im Prinzip ist das genau der Zustand den wir jetzt haben, bzw. was ich vorgeschlagen habe: Alle Elemente werden einzeln eingetragen und dann legt man eine Relation an, in der man angibt, dass diese Elemente zusammengehoeren. Moeglichkeit 2: Das soll automatisch gepflegt werden. Dann muss wiederum bei jeder noch so kleinen Aenderung die komplette Datenbank durcsucht werden, ob sich dadurch irgendwelche Zugehoerigkeiten geaendert haben. Das scheint mir auch nicht wirklich praktikabel. Noch ein paar Anmerkungen zum direkten Eintragen an den Einzelelementen: 1. Wir haben viele tausend Mapper aber nur ein paar dutzend Leute, die sich um die Pflege und Entwicklung der verschiedenen Softwarekomponenten kuemmern. Insofern halte ich es fuer einen guten Ansatz, moeglichst viel Fleissarbeit beimn Eintragen in die Datenbank zu investieren, wenn das die Arbeit beim Ausweten der Daten erleichtert. 2. Mit einem Editor wie JOSM kann man ja auch alle Mitglieder einer Relation auf einen Schlag anwaehlen und so eine Aenderung parallel bei allen Mitgliedern durchfuehren. Also sonderlich viel Mehraufwand entsteht dabei nicht mal. 3. Wenn man die Daten mehrfach gespeichert hat, dann steigt natuerlich die Wahrscheinlichkeit, dass bei einzelnen Elementen mal ein Fehler auftritt. Dafuer wirkt sich der Fehler dann aber auch nur auf das einzelnen Element aus. Man kann also auch nicht so leicht ausversehen grossen Schaden anrichten. Die gleiche Diskussion gibt es ja auch immer mal wieder bei aenlichen Anlaessen. Bezueglich der geschlossenen Ortschaften werden die wildesten Konstrukte vorgeschlagen, wie z.B. aus eingezeichneten Ortsschildern automatisch solche Umschliessungen berechnet werden sollen. Der Gegensatz findet sich bei den politischen Zuordnungen, wo z.Z. mit verschiedenen Ebenen von is_in-Tags geabeitet wird. So richtig gluecklich sieht das mit etwas Abstand betrachtet nicht aus, aber immerhin wird da ordentlich Erfahrung in der Praxis gesammelt. Da wird die Zeit dann zeigen, wie sich das bewehrt. Gruss Torsten
Das ist eine Frage der Datenstruktur und durchaus mit “geringem” Aufwand möglich. Wenn man nicht nur auf vorproduzierte Kacheln zugreifen möchte, dann ist das sowieso notwendig. Wir bewegen uns ja durchaus in einem abgeschlossenen und endlichen Koordinatensystem.
Wenn eine Area hochgeladen wird müssten die IDs der Objekte die sich in der Area befinden in eine neue Tabelle gespeichert werden. Diese Tabelle wird dann einfach mit abgefragt… Also ziemlich simpel…
Genau desswegen sollte man von den Editoren und Renderern nicht zu viel erwarten… Wenn das auf Seite der API läuft, dann brauchen sich die Programmierer darum nichtmehr zu kümmern. Zumal es auch in Zukunft noch möglichst einfach sein soll die Daten aus der Datenbank ohne viel Aufwand sinnvoll zu verwerten. Nehmen wir mal als Beispiel mal die Postleitzahlen… Um die ohne viel Aufwand rendern zu können brauch man das Area-Polygon. Fürs Routing bräuchte man wiederum Informationen direkt an den Wegen. Wenn der Weg also eine Info hätte zu welchem Area-Polygon es gehört, und von wo bis wo, dann wär beides Erfüllt. Normale Relationen haben den Nachteil, dass man sie selber erstellen muss, obwohl das Polygon eigentlich die Fläche schon vorgibt. Außerdem müssten bei normalen Relationen die Wege immer genau am Ende der Area gesplittet werden. Klar könnten das die Editoren auch automatisch machen. Aber das macht es für Entwickler nicht besonders attraktiv einen Editor zu schreiben…
Und eben weil hier soviele daran herumdoktern, ist dieses komplett manuelle ein Problem. Wir haben hier Straßen mit jeweils bis zu mehrern hundert Adressen. In der bisherigen Relation muss das händisch überprüft werden. Bei normalen Wegen lässt sich das ja dank Tool automatisch überpüfen. Da ist schnell geklärt ob etwas fehlt. Dank Entfernungsangaben, Koordinaten, Kartendarstellung und Beschreibung des möglichen Problemverursachers (z.B. noch nicht unterstützter Kreisverkehr) sogar Idiotensicher. Das geht mit unzusammenhängenden Einzelobjekten nicht. Wenn nun einer etwas ändert und die Relation vergisst, ist die Hausnummer herrenlos und im Routing nicht mehr existent. Wenn das mehrfach passiert dann bekommt der Käse Löcher. Stichwort Potlatch. Das Teil ist ja ganz nett um in dünn gemappten Gebieten mal schnell einen POI zu setzen. Die meisten Fehler kommen aber von eben jenem “Editor”. Das kommt zum einem weil er bei zu vielen Daten oder ausgelastetem Server hängt, schnell mal mit ganzen verschobenen Wegen und anderem Datenmüll ungesehen abkracht und durch den direkten Schreibzugriff auf die Datenbank direkt speichert. Oftmals bleibt der Fehler dann am nächsten hängen oder ewig im System liegen. Was ich da schon fixen durfte… nun gut. Unsere Notepad unter den OSM Editoren zieht aber naturgemäß vor allem Leute an, die es gerne einfach haben, mit den eigentlichen einfachen richtigen Editoren nichts anfangen können und sich so oftmals wenig oder nur sehr dünn mit der Materie vertraut gemacht haben. Aber gerade da muss ich mich ja noch besser auskennen. Denn Potlatch meckert, anders als z.B. JOSM, nicht, wenn ich irgendwas aus einer Relation heraus lösche. Lieschen Müller produziert so unabsichtlich ganz schnell Mist. Nun kann ich aber nicht jedem Lieschen ein rtfm entgegen schreien. Das wird nie fruchten, was ich aus jahrelanger Erfahrung als Freeware Autor nur allzu schmerzlich lernen musste. Du kannst eine noch so kurze und einfache Readme schreiben. Minimum 60% liest sie nicht und legt einfach los, löchert dich beim scheitern mit bereits in der Readme geklärten Fragen oder haut komplett in den Sack, bei solchen Dingen wie hier mit einem liegen bleibendem Scherbenhaufen. Da bleibt nur eines. Ich muss das System quasi Idiotensicher gestalten. Also bringe ich z.B. dem Potlatch bei nicht alles ohne kritische Nachfrage zu übernehmen. Oder ich automatisiere in der API eben einige potentiell fehleranfällige Dinge. Bisher braucht es ja da den ortskundidigen Oberinspektor Schulze, der dann ständig manuell kontrolliert und bei Bedarf fixt. Das arme Schwein was beispielsweise die Fühlsbüttler Straße in Hamburg, mit knapp 800 Adressen, so kontrollieren muss, tut mir ehrlich gesagt so richtig leid. Sowas sollte möglichst automatisiert drinnen sein, ansonsten ist das bei einem detailreichem und komplexem Datenbestand nicht mehr machbar. Einfache Relationen reichen noch bei der Dorfstraße 1 bis 31. Klar kann ein Datenverlusst auch mit automatisch vererbendem Poly passieren. Nur muss man da schon Objekt oder Daten komplett löschen. Das lässt sich aber einfacher kontrollieren. Wenn mir das Poly gestern 900 Adressen meldete, heute aber nur noch 831, weiß ich ohne weiter nachgucken zu müssen, da hat uns einer 69 Adressen “geklaut”. Wenn das Poly mir dann auch noch Objekte ohne Datensätze oder Lücken filtern kann, hält sich die Pflege in Grenzen. Eine Relation sagt mir zwar auch die Anzahl der eingebundenden Objekte, jedoch nicht, ob der Datenbestand der an diesen Objekten hängt auch vollständig ist. Das muss ich händisch für jedes einzelne Objekt herausfinden, oder die Werte per Suche mit JSOM abklopfen und das Gebiet visuell nach nicht markierten Objekten absuchen. Das mag bei einer Kuhbläke ja noch angehen, aber ab Mittelzentrum aufwärts, wird das ganze frustrierend.
@ Mirko Küster: Ich stimme dir 100%ig zu. Und da sich jeder einen Editor programmieren kann wie er lustig ist, ohne solche Dinge zu berücksichtigen, wärs halt schön wenn das von der API übernommen werden würde…
Ok, Also bezüglich meiner Anfangsfrage kann ich also zusammenfassen, daß es keine gute Lösung gibt und eine Idee wäre, mit den bestehenden Mitteln was zu “frickeln” (also zusammenhängende Waldstücke zu zerlegen und unterschiedlich zu taggen usw.). Wie sollte man denn weitermachen, um eine vernünftige Lösung zu etablieren?
Ob nun gut oder schlecht ist Ansichtssache: die Loesung hat sicherlich ihre Vor- und auch ihre Nachteile. Momentan sehe ich allerdings keine brauchbaren Alternative.
Das ist eine gute Frage. Die naechste Api-Version ist ja im Anflug, aber ehrlich gesagt habe ich keine Ahnung, in welchen Forum oder in welcher Mailing-Liste das im Vorfeld diskutiert wurde. Ich schaetze mal http://lists.openstreetmap.org/listinfo/dev. Ein so grosser Umbau der Datenbank, wie er hier vorgeschlagen wuerde, wird aber sicher nicht in den naechsten Tagen zu erreichen sein. Gruss Torsten
Ich gehe mal davon aus, dass du meinen Vorschlag meinst… Eigentlich ist das kein großer Umbau der Datenbank, sondern nur einen zusätzliche Tabelle. Allerdings wär das Ermitteln der Daten die in die Tabelle gehören wohl etwas aufwändiger, davon hab ich aber nicht soo viel Ahnung. Ich denk aber auch, dass wir sowas in der kommenden API noch nicht erwarten dürfen.