Grenzen Truppenübungsplatz

Das mit dem umfassenden Polygon sehe ich nicht zwingend so. Ich wuerde alle Abschnitte einzel zusaetzlich zum landuse als military markieren. Dann ist schon mal sicher gestellt, dass da die Information richtig drin steckt. Wer ausdruecken will, dass die verschiedenen Abschnitte gemeinsam das Militaergelaende bilden, der kann ja eine entsprechende Relation anlegen, bei der die einzelnen Abschnitte die Member sind. Gegen das allumfassende Polygon spricht aus meiner Sicht, dass damit das Problem unnoetig in Richtung Renderer verlagert wird. Wenn der Renderer nicht genau die Ueberlegeungen des Mappers kennt (Stichwort trabnsparentes Overlay), dann kommt da auch nur entsprechender Bloedsinn bei raus. Und ich wuerde ganz dringend dazu raten, denn durch so ein Gelaende fuehrenden Wegen eigene Access-Tags zu spendieren: 1. Sind diese haeufig anders als fuer das retsliche Gelaende (Benutzung der Wege ist erlaubt, Verlassen der Wege verboten). 2. Hat man dadurch lediglich geringen Mehraufwand einmalig beim Eintragen. Alternativ muss jedes Routing-Programm, dass da in Zukunft kommen mag, erheblichen Mehraufwand reinstecken, um nachtraeglich sich die Information aus dem Polygon abzuleiten. (Wobei wie unter 1. erwaehnt ja nicht mal sicher ist, dass das gewuenscht ist.) 3. Aus 2. folgt auch, dass man nicht sicher sein kann, dass der gerade benutzte Router eine entsprechende Logik eingebaut hat, um sich die Access-Information aus dem Polygon abzuleiten. Ok, man kann grundsaetzlich nicht sicher sein, dass der Router mit Access-Restrictionen umgehen kann. Aber wenn sie direkt an der Strasse eingetragen sind, duerfte es doch um einige Nummern wahrscheinlicher sein. Gruss Torsten

Bin auch der Meinung, dass man die Wege zusätzlich mit access-tags versehen sollte… Die können ja auch innerhalb des Polygons unterschiedlich sein… @de_muur: Was meinst du mit den Abschnitten, die du als military markieren willst?

Ich wuerde jeden Wald einzeln als landuse=forest military=danger_area access=… eintragen, und jedes Feld entsprechend landuse=farm military=danger_area access=… oder auch natural=scrub military=danger_area access=… und so weiter. Diese einzelnen Gebiete meinte ich mit “Abschnitte”. Anstatt da ein grosses Polygon mit military=danger_area oben drueber zu stulpen, wuerde ich stattdessen das Tag bei jedem Einzelteil setzen und alle zusammen dann in einer Relation zusammenfassen. Gruss Torsten

Genau desshalb wird doch sowas ausgearbeitet und dokumentiert. Das die Render da nich sofort hinterher kommen ist klar. Selbst vieles wirklich einfaches hat man heute noch nicht drauf. Aber nur weil es da schleift, kann man doch die Entwicklung ansich nicht schleifen lassen. Das ist do so wie wenn ich nix mehr für Linux entwickeln würde, nur weil sich die Programmier der angebotenen GUI immer Zeit lassen sowas zu implementieren. :smiley: Die Sache mit dem schlauen Polygon würde eine Menge an Arbeit und Daten einsparen und viele Mischformprobleme beseitigen. Das Teil muss nur nur alles in sich vereinen und damit entsprechend automatisch kennzeichen. Es sind auch Ausnahmen drin. Node, Way oder Relation xyz wird per Regel ausgenommem und erscheint für Renderer und Routing normal. Der riesen großteil an abgehenden Wegen und Gebieten erhalten aber automatisch ihre Einschränkungen und in der optischen Darstellung z.B. die halbtransparenten Panzer. So muss doch jedes einzelne Objekt im Gebiet händisch geändert und jeweils mit zusätzlichen Daten versehen werden. Da fallen mir auf Anhieb dutzende Möglichkeiten und gelöste Probleme ein. Sperrgebiete, Eisenbahngelände, Flughäfen, Steinbrüche mit Straße und Sprengsperrzeiten, Ortslagen (Adressen, eingebettete Stadtwälder, Industrie etc.), riesige Landwirtschaftsgebiete die aber von Wäldchen usw. unterrochen sind… Alles Dinge bei denen man sich bisher zwischen dem einem oder anderem entscheiden, oder mit Multipolygonen, Layer, Wege nahe anderem Weg Fehlern und einer Unzahl von doppelten unnötigen und Backend sinnlos belastenden Daten herumschlagen musste. Da lässt sich die Datenbank mit einem Index für vieles und versclankten Redundanzen deutlich entlasten. Die dutzendfach angewendeten und undokumentierten Notlösungen und damit potentiellen Fehlerquellen werden hinfällig. Und Anwenderfreundlich und damit zeitsparender ist das ganze auch noch. Lohnt es sich wirklich nicht mal darüber nachzudenken und stattdessen wieder die 1.000.001 undokumentierte Nötlösung ins System einzubringen?

Da die OSM-Datenbanken Systembeding nie fehlerfrei sein werden, sind Redundanzen alles andere als unwichtig. Und mit “Anwenderfreundlich und damit zeitsparend” denkst du jetzt nur an den Mapper. Aber der eigentlich Anwender ist doch derjenige, der die Daten aus der Datenbank benutzen will (z.B. Renderer oder Router). Um bei dem einmaligen Eintragen ein paar Minuten zu sparen willst du spaeter die staendige Nutzung aufwendiger gestallten. Und was du hier vorschlaegst, vereinfacht die Sache auch nur, solange man in der heilen Geradeauswelt denkt. - Wenn man sich nur einen kleinen (was auch imme rklein ist) geographischen Ausschnitt der Datenbank anschaut, woher soll man dann wissen, ob dieser Ausschnitt auch alle relevanten Informationen enthaelt? Vielleicht hat da ja jemand ein grossen Polygon aussenrum gezeichnet, was einem noch Informationen zu den Elementen innerhalb des Ausschnittes liefert. um das ueberprüfen zu können, müsste man für jede kleine abfarge immer da skomplette Wordlfile bemühen. - Das umfassende Polygon muss ja nicht die gleichen Grenzlinien haben wie die anderen Flaechen- und Linienelemente. Um das dann richtig analysieren (nicht nur anzeigen) zu koennen, muessen dann die Auswerteprogramme an den Schnittstellen selber neue Hilfsknoten einfügen. Was da fuer ein Aufwand bei den verschiedensden Sonderfällen enststehen wird, kann sich ja wohl jeder selber vorstellen. Also in meinen Augen wird dein Ansatz die 1.000.002 Kruecke im System. Und weil das ja jeder anders beurteilt, haben wir bereits 1.000.001 davon. Gruss Torsten

Ich sag ja … wenn man da was ändert, dann muss man beim landuse=military ansetzen. Das müsste ersetzt werden mit den Regeln, die noch zu besprechen sind… Es macht kein Sinn sich was tolles Auszudenken, und es taggt trotzdem jeder alles einfach mit landuse=military…

Eben, das Problem haben wir ja z.B. bei den Adressen. Das sind 10.000 Objekte mit gleichem Ort und Postleitzahl. Macht 19.998 überflüssige Werte, die 2 verblieben gehören übergeordnet und zeigen auf alles darunter.

Umgekehrt muss sich der Mapper also individuelle und damit undokumentierte suboptimale Notlösungen ausdenken und die Datenbank zumüllen, weil der Programmierer am anderen Ende entweder nur unzureichende Kenntnisse betsitzt, oder warum auch immer gerade keinen Bock hat? Ich dachte immer das es so läuft, das sich beide Seiten einem optimalem Ergebnis nähern. Und davon sind wir momentan weit weg. Mit weiter so kommen wir nicht vorwärts.

Also da denke ich schon weiter um die die Ecke als du :smiley: Denn…

So wie jeder Weg usw. schon jetzt seine Zugehörigkeit zu einer Relation meldet, kann das auch mit Polygonen, Tesseracten, oder Paralelogrammen passieren. Es muss dem Editor nur bigebracht werden. Der Aufwand dürfte nicht groß sein.

Genau das ist doch der Knackpunkt. Damit enfallen dutzende überflüssige Splits, die wiederum eine Menge an überflüssigen Daten produzieren. Wie sich das lösen lässt oder nicht, entscheiden die entsprechenden Programmierer. Und bevor die noch nix dazu gesagt haben, haue ich doch nicht wegen einem Problem in den Sack, das ich mir vielleicht nur einbilde, weil ich es mir mangels Fachwissens komplizierter vorstelle, als es in Wirklichkeit ist. Lass doch erstmal die entsprechenden Fachleute zu Wort kommen.

Never, mir sind da schon unzählige Krücken aufgefallen, die damit gelöst wären. Die Krücken können nur weniger werden.

Nicht nur bei Military. Wir haben einen Arsch voll Tags die in der Realität anderes umschließen oder schneiden. Desshalb muss man sich auf das gesamte Problem konzentrieren und nicht nur auf einzelne Teile. Und letzterem muss man eben mit einem Standard begegnen. Der muss natürlich be- und anerkannt sein. Dann hören auch die Krücken auf.

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