Grenzen Truppenübungsplatz

Moin, Ich bin schon länger auf der Suche, wie ein Truppenübungsplatz oder andere Sperrgebiete richtig einzuzeichnen sind. Gefühlsmäßig wäre das ja nur eine Grenze, die als Außengrenze gezeichnet werden müsste. Allerdings habe ich bislang nur Beschreibungen als Landuse gefunden. Das führt dann aber zu Problemen, wenn große Truppenübungsplätze auch Teile eines Waldes beinhalten. Entweder sieht man das Sperrgebiet nicht, weil der Wald drüber liegt oder aber, wenn man mit layer arbeitet, verdeckt das Sperrgebiet den Wald. Kartenmäßig ist ein Sperrgebiet ja keine besondere Landfläche sondern nur ein Gebiet mit Beschränkungen, weswegen ich eine Art Grenze sinnvoller ansehe. Oder habe ich was übersehen? Das führt mich dann auch nahtlos zu Straßen. Ich weiß von Deutschland, Frankreich und Finnland, daß es Sperrgebiete gibt, durch die auch öffentliche Strassen führen. Die abzweigenden Straßen/Wege sind dann entweder mit Sperren versehen (das wäre ja kein Problem) oder offen und mit Schildern versehen, weil sie auch im Übungsbetrieb ständig befahren werden. Wie sollte man diese Strassen markieren, so daß ein evtl. Router diese nicht als kürzeste Verbindung von A nach B ansieht, solange man kein Panzer ist?

Wie wäre es mit access=no oder motorcar=no

Möglich, aber zu absolut. Klärt aber nicht die Grenzen des Sperrgebiets, oder?

was ist denn an landuse=military so schlimm? Das land wird halt zu Militärzwecken genutzt… und gleichzeitig als Wald. :wink: Ob und wie das gerendert wird, das ist Sache des Renderers…

landuse gibt ja eine Flächennutzung in Bezug auf Bewirtschaftung/Bebauung an. Ein Sperrgebiet ist aber in erster Linie erstmal eine rechtliche Einordnung. Häufig ist es durch Beschilderungen abgegrenzt und daß Straßen, die hereinführen, gesperrt sind. Straßen, die durchführen und befahren werden dürfen, sind die Ausnahme. Je nach Land und Sperrgebiet gelten auch andere Regeln/Gesetze innerhalb des Gebietes, wenn man die öffentlichen Wege verläßt, sofern vorhanden. Das ist so ähnlich wie mit Ortsgrenzen, die ja auch abweichend von bebauten Gebieten sind.

Finde das äusserst interessant :wink: Aus dem Bauch heraus: landuse=miltary access=no Ansonsten ginge wohl auch military=danger_area landuse=military access=no Über wood=natural könnte man auch nochmal nachsinen. Ist zwar kein Urwald… allerdings ob auf einen Truppenübungsplatz der Wlad bewirtschaftet wird :wink:

Er wird bewirtschaftet. Ein unbewirtschafteter Wald sieht doch deutlich anders aus und ist zum Kriegspielen auch nicht sonderlich gut geeignet (u.a. hoehere Unfallgefahr, wenn Baeume nicht gezielt entfernt werden sondern nach Lust und Laune umkippen duerfen). Insofern hat man es hier wohl mit Gebieten zu tun, die auf zwei Arten genutzt werden. Wie waere es mit military=danger_area landuse=forest (fuer die bewaldeten Bereiche) access=… (welcher Zugang dann wann auch immer erlaubt ist) Da hat man beide Informationen in der Datenbank, was davon dann wie in der Karte angezeigt, bleibt dem Renderer ueberlassen. Ein Sperrgebiet nur als Grenze zu betrachten hilft einem nicht weiter, wenn man nur einen kleinen Ausschnitt aus der Karte betrachtet, der komplett innerhalb des Gebietes liegt. Insofern macht es schon Sinn, dass man das wirklich als Gebiet behandelt. Wenn eine oeffentliche Strasse durch das Sperrgebiet fuehrt, würde ich das Sperrgebiet in zwei Teile jenseits der Strasse aufteilen, da hierfuer ja sicherlich auch andere Zugangsbeschraenkungen gelten. Der Strasse wuerde ich dann ein eigenes access-Tag spendieren. Gruss Torsten

Wie schon gesagt: Solche Wälder sind auch bewritschaftet. In diesem Gebiet: http://www.openstreetmap.org/edit?lat=51.7634&lon=7.2851&zoom=13 gibt es an der Ostseite auch Felder, die zwar innerhalb der Grenzen liegen, aber normal bestellt werden (ob die Bauern Entschädigung für Flurschäden bekommen oder einfach keine Pacht zahlen, weiß ich nicht). Bei anderen liegen ganze (verlassene) Orte darin. Nur im Sandkasten spielen wäre auf Dauer langweilig … Wenn man jetzt die einzelnen Geländeformen Wald, Felder, Sand erfasst, dann gehört da ja eine gemeinsame Grenze drum. Man könnte natürlich alles, was über die Grenze hinweg geht, teilen und jeweils die zugehörigen mit “military” taggen, aber dann hat man vom Datenbestand her ja verschiedene Einzelelemente, obwohl es doch eigentlich ein ganzes war. Diejenigen, die auch Luftverkehrsdaten erfassen, benötigen die Grenzen meist ja auch (egal, welches Terrain), weil entsprechende Beschränkungen vorliegen. Im o.g. Beispiel sieht man dann auch, was Renderer aus dem “landuse” machen. Anstelle der roten Grenzlinie, die man in normalen Karten sieht, verschwindet es unter dem Wald oder, wenn man mit layers arbeiten würde, überdeckt den Wald und damit die Hinweise auf das Landschaftsbild.

Ob landuse nun als Grenze oder Fläche gerendert wird hängt immer vom Renderer ab… Und für den taggen wir ja nicht. :wink: Aber dann tag die Grenze doch einfach nur mit military=danger_area und access= Und Landuse für Wald usw. kannst du dann ja extra machen…

Im Moment taugt da wirklich nur eine Grenze um das Sperrgebeit herum. Das Problem habe ich hier teilweise auch. Wir haben mehrere Standort- und Truppenübungsplätze. Manche noch aus NVA und GSSD Zeiten. Die einen wurden nachgenutzt, andere sind freigebeben und wieder andere sind wegen Rüstungsaltlasten teilweise, ganz oder punktuell gesperrt. Da auch mit Wald, Feld, Landstraßen und Wanderwegen mitten hindurch. Auch hier fehlt wieder das “schlaue Polygon”, welches alles darin entsprechend automatisch zuordnet. Damit könnten die Renderer auch entsprechendes machen. Zum Beispiel einen transparenten Layer mit halbtransparenten Panzern darüber legen. Eben analog zum entsprechendem Landuse. So wären diverse Mischvarianten drin, ohne bei dem einem oder anderem Abstriche machen zu müssen.

Wieso habe ich das Gefühl, daß “Renderer” ein Signalwort ist, welches den Rest eines Postings in den Hintergrund schiebt? Was der Renderer daraus macht, ist ja erstmal unwichtig. Aber das Polygon besagt ja folgendes: - Im Bereich abweichende terrestrische Verkehrsregeln - Zutrittsbeschränkungen - Auswirkungen in den Luftraum (weswegen u.a. landuse eine schlechte Wahl wäre) - teilweise politische (hoheitliche) Auswirkungen (es gibt Länder, in denen solche Sperrgebiete verwaltungstechnisch nicht dem Bezirk zugeordnet sind sondern einer anderen Instanz) - Effekt auf den Renderer, der den Bereich entsprechend markiert military=danger_area hört sich für mich schon mal besser an als landuse. Wobei military=training_area oder military=shooting_range oder military=restriction_zone für verschiedene Arten besser wäre. Oder? Sollte man dann alle Strassen/Wege die rein führen, an der Kante mit gemeinsamen Nodes versehen oder soll man sich darauf verlassen, daß Router oder Renderer es auch ohne diese Nodes hinbekommen?

Genau so sehe ich das auch… Vorher klang das für mich so, als würdest du dich vor allem am Rendering stören… Ich denke mal genauso wie dus beschreibst hat sich das der erfinder von landuse=military auch gedacht. Also im Prinzip gehts nur darum, dass “landuse” nicht passt… Das würde dann aber auch bedeuten, dass landuse=military generell garkein Sinn machen würde. Daher müsste man sich mal darum bemühen einen anderen Key vorzuschlagen, und durchzusetzen, damit landuse=military generell in ***=military geändert wird… Oder hab ich da jetzt wieder irgendwas völlig missverstanden? Edit: … nur nochmal zum Verständis … wir haben auf jeden Fall ein Polygon, was die Fläche umrahmt. Und die Frage ist nur, wie wir dieses Polygon taggen, oder?

Yupp. Man könnte sich dann noch darüber unterhalten, ob alle Straßen/Wege die rein führen, einen gemeinsamen Node mit dem Polygon haben sollen. Das würde Autoroutern das Leben einfacher machen (ähnlich der Diskussion um Ortsschilder). Edit: Ach, das hatte ich auch schon oben gefragt.

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.