Grenzen Truppenübungsplatz

tante ju wrote:

Moin, .... 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

ersthelfer wrote:

tante ju wrote:

Moin, .... 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. 😉 Ob und wie das gerendert wird, das ist Sache des Renderers...

TEL0000 wrote:

was ist denn an landuse=military so schlimm? Das land wird halt zu Militärzwecken genutzt... und gleichzeitig als Wald. 😉 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 😉 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 😉

Islanit wrote:

Über wood=natural könnte man auch nochmal nachsinen. Ist zwar kein Urwald... allerdings ob auf einen Truppenübungsplatz der Wlad bewirtschaftet wird 😉

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

de_muur wrote:

Islanit wrote:

Über wood=natural könnte man auch nochmal nachsinen. Ist zwar kein Urwald... allerdings ob auf einen Truppenübungsplatz der Wlad bewirtschaftet wird 😉

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.

Wie schon gesagt: Solche Wälder sind auch bewritschaftet. In diesem Gebiet: http://www.openstreetmap.org/edit?lat=5 … 51&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. 😉 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.

TEL0000 wrote:

Ob landuse nun als Grenze oder Fläche gerendert wird hängt immer vom Renderer ab... Und für den taggen wir ja nicht. 😉 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...

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?

tante ju wrote:

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

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?

TEL0000 wrote:

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.

tante ju wrote:

TEL0000 wrote:

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?

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).

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?

TEL0000 wrote:

@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

de_muur wrote:

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.

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. 😄 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?

Mirko Küster wrote:

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

Mirko Küster wrote:

Lohnt es sich wirklich nicht mal darüber nachzudenken und stattdessen wieder die 1.000.001 undokumentierte Nötlösung ins System einzubringen?

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...

de_muur wrote:

Da die OSM-Datenbanken Systembeding nie fehlerfrei sein werden, sind Redundanzen alles andere als unwichtig.

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.

de_muur wrote:

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.

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.

de_muur wrote:

Und was du hier vorschlaegst, vereinfacht die Sache auch nur, solange man in der heilen Geradeauswelt denkt.

Also da denke ich schon weiter um die die Ecke als du 😄 Denn...

de_muur wrote:

- 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.

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.

de_muur wrote:

- 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.

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.

de_muur wrote:

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.

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

TEL0000 wrote:

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...

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.

Mirko Küster wrote:

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...

TEL0000 wrote:

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ß.

tante ju wrote:

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....

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.

tante ju wrote:

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ß.

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..

TEL0000 wrote:

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

de_muur wrote:

TEL0000 wrote:

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.

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.

de_muur wrote:

TEL0000 wrote:

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.

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...

de_muur wrote:

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.

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...

TEL0000 wrote:

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?

tante ju wrote:

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.).

Ob nun gut oder schlecht ist Ansichtssache: die Loesung hat sicherlich ihre Vor- und auch ihre Nachteile. Momentan sehe ich allerdings keine brauchbaren Alternative.

Wie sollte man denn weitermachen, um eine vernünftige Lösung zu etablieren?

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

de_muur wrote:

Ein so grosser Umbau der Datenbank, wie er hier vorgeschlagen wuerde, wird aber sicher nicht in den naechsten Tagen zu erreichen sein.

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.