Müssen alle Zwischenräume mit Flächen gefüllt sein?

ronzen · 2013-04-18 12:37:46

Also, irgendwie kapier ich das jetzt nicht. Der Zaun als "Linie" soll nicht mit der Weide in Verbindung stehen, die Straße, auch eine "Linie", muss an die Weide geheftet werden?

Jo, das hat den ganz einfachen Hintergrund, dass wir das Polygon als "meadow" taggen und nicht "willow" oder sowas. Mit "Weide" meinst du mit Sicherheit den Teil der Wiese, der genau mit dem Zaun abgerenzt wird. Aber wir setzen keine Weiden, sondern Wiesen..

reneman · 2013-04-18 13:36:39

http://us.123rf.com/400wm/400/400/matur … enrand.jpg
oder

reneman · 2013-04-18 13:45:11

Abstracte KunstDarstellung (Quelle: Own Work), Positionierung beim Mappen erfolgt genau da, wo sich das Objekt lt. Luftbild befindet. Sollte sich zwischen Zaun und Straße ein Graben oder ein Grünstreifen befinden, so wird dieser ebenfalls an exakter Position ohne Verbindung zur Straße gemappt.

Last edited by reneman (2013-04-18 14:13:39)

ronzen · 2013-04-18 13:53:56

Jup, auch hier wieder gleiches Vorgehen: meadow an track (dieser hat eine gewisse Breite, definiert zur seinen Typ, die der Linie zu- und der Wiese abgezogen wird). Der Zaun wird da entlang gezogen, wo er zu erkennen ist.
Bei der Auswertung wird der Straße die entsprechene Breite zugewiesen, und es ergibt sich das Bild wie auf dem Foto.

Was ist denn, wenn der Bauer Bock hat und den Zaun sternförmig auf der Wiese aufstellt? Wird der dann auch bis zu seinen Grenzen mit einer Fläche "meadow" gefüllt um zwischen (exaktem) Straßenrand und Zaun nochmals ein meadow zu legen? Oder dann gar mit "gras", weil nicht landwirtschaftlich genutzt? Und was ist nächstes Jahr, wenn der Zaun woanders steht?

Grüße

Edit: Kannst du die Quelle des Schemas bitte mal verlinken? Der dazugehörige Artikel würde doch interessieren, glaube ich.

Last edited by ronzen (2013-04-18 14:05:35)

wambacher · 2013-04-18 16:04:39

ronzen wrote:

Jup, auch hier wieder gleiches Vorgehen: meadow an track (dieser hat eine gewisse Breite, definiert zur seinen Typ, die der Linie zu- und der Wiese abgezogen wird)

Ich glaube, da liegt du voll daneben:

Ein Way hat in OSM keinerlei Breite sondern ist ein einfache Linie ohne seitliche Ausdehnung. Freundlicherweise "malen" die Renderer eine vom Typ abhängige breitere Linie auf die Karte und überdecken somit die dort von dir eingezeichneten Flächen um einen gewissen Betrag. Somit ist es nur den Renderen zu verdanken, dass deine Konstrukte in Grafiken "sauber" aussehen.
Für andere Anwendungen relevante Informationen wie z.B. die Fläche /Größe eines Landstückes werden von dir falsch erfaßt, da du die Flächen ja künstlich größer machst als sie in der Realität sind. Und das ist falsch.

Diese Vorgehensweise fällt in die Kategorie "Taggen für den Renderer" und wird gerne von Newbies (*) verwendet, denen einzig und alleine das optische Erscheinungsbild der Karte wichtig ist.

wambacher

*) ich hätte mich jedenfalls nicht getraut nach ca 80 Tagen Mapper-Erfahrung so selbstsicher zu definieren, was richtig oder falsch ist und wie es gefälligst zu erfassen ist.

Wolfgang B · 2013-04-18 16:15:13

Entweder bin ich zu alt oder zu lange bei OSM dabei: Ich kapiere es immer noch nicht: Was ist der Unterschied zwischen Straße und Zaun, dass ich das eine an die Fläche heften muss und das andere nicht darf? Gras ist links und rechts der Straße, also müsste ich nach deinem Dafürhalten doch die Straße über die Fläche ziehen ...

streckenkundler · 2013-04-18 16:16:09

ronzen wrote:

Bei der Auswertung wird der Straße die entsprechene Breite zugewiesen

So wird es beim ATKIS auch gemacht. Vergleiche das GeoInfoDok bei AdV Online. Hier sind aber i.d.R. Straßenbreiten, Fahrstreifenanzahl ect. angegeben und die Objektbildungsregeln sind reichlich kompliziert.

Das darf aber insgesammt nicht alleine gesehen werden, denn es geht einher mit dem ALKIS, das flurstücksbasierend ist.

Die Abstraktion die du willst und die das ATKIS verwendet funktioniert aber nur bis zu bestimmten Maßstäben. Es werden Informationen generalisiert. Bei Darstellungsmaßstäben größer als 1:10.000, also 1:5000 oder größer funktioniert diese Kartierweise nicht mehr. Hier müssen solche linearen Objekte (gerade Straßen, Gewässer, Bahnflächen(nicht Gleise!)*1) irgendwann als Fläche erfasst werden.
Bei diesen drei Gruppen kommt man dann dahin, daß man beides haben muß: das Linienobjekt, daß Straßeneigenschaften i.d.N. fürs Routing trägt und das Flächenobjekt, daß Basis fürs Kartenrendering vor allem bei großmaßstäbigen Karten ist; bei mittel- bis kleinmaßstäbigen Karten ersetzt dann z.B. das Linienobjekt der Straße die Fläche.

Schaue dir mal bitte eine K5 an (Karte im Maßstab 1:5000). Diese sind nicht mehr generalisiert und Kartenobjekte in ihrer realen Größe dargestellt: Straße ist eine Fläche, keine Linie.

Nicht umsonst gibt es Tagging-Vorschläge wie
http://wiki.openstreetmap.org/wiki/Prop … ea:highway

Gruß,
Sven

*1) deswegen funktioniert auch http://forum.openstreetmap.org/viewtopic.php?id=20875 nicht.

reneman · 2013-04-18 16:39:01

Wolfgang B wrote:

Entweder bin ich zu alt oder zu lange bei OSM dabei: Ich kapiere es immer noch nicht: Was ist der Unterschied zwischen Straße und Zaun, dass ich das eine an die Fläche heften muss und das andere nicht darf? Gras ist links und rechts der Straße, also müsste ich nach deinem Dafürhalten doch die Straße über die Fläche ziehen ...

Bitte mach dich nicht am Zaun fest
Ich habe eindeutig geschrieben, dass die Objekte dort zu kartieren sind, wo sie in der Realität auch zu finden sind. Wenn der Zaun quer über die Wiese geht, dann wird er quer über die Wiese gemappt. Es wurde jedoch vorhin darüber gesprochen, wie es sich verhält, wenn direkt am Straßenrand ein Zaun steht und direkt hinter dem (bzw. am) Zaun eine Wiese beginnt (vgl. Foto #2013-04-18 14:36:39).

Last edited by reneman (2013-04-18 16:42:57)

chris66 · 2013-04-18 16:39:15

streckenkundler wrote:

Nicht umsonst gibt es Tagging-Vorschläge wie

Ebend. Im Prinzip haben wir das alles. waterway+riverbank, highway+highway:area (eventuell bräuchte man ergänzend noch ein landuse=traffic),
landuse=railway (wird sogar gerendert), etc. pp.
Chris

streckenkundler · 2013-04-18 17:17:27

chris66 wrote:

landuse=traffic

für solche Mischnutzungen? z.B. Bahnübergänge?

chris66 wrote:

landuse=railway

Sehe ich viel zu selten in der Anwendung und wenn dann nur Bahnhöfe... Das ist genausogut für die freie Strecke geeignet, gehört dort auch hin und ich wende es auch so an.

Sven

ronzen · 2013-04-19 00:48:25

Wolfgang B wrote:

Was ist der Unterschied zwischen Straße und Zaun, dass ich das eine an die Fläche heften muss und das andere nicht darf? Gras ist links und rechts der Straße, also müsste ich nach deinem Dafürhalten doch die Straße über die Fläche ziehen ...

Da scheinst du was falsch aufgegriffen zu haben. Niemand hat behauptet, dass man Straßen an Wiesen heften muss. Nein, wenn ein Weg über die Wiese führ, dann macht dieser Weg freilich nicht zwei Wiesen draus..
Hingegen wäre es - in meinen noob-Augen - inkonsequent zu sagen, man darf angrenzende Flächen nur bis zur Fahrbahngrenze ziehen, um jene noch einzeichnen zu können - in anderen Situationen aber Wege gnadenlos über die Felder zu zerren.

Vielen Dank, streckenkundler, für deinen wirklich wertvollen Beitrag. Ich habe bisher noch nie etwas über dieses Anwendungsschema gehört und war sofort der Meinung, dass OSM ebenfalls so etwas braucht. Da steht ja alles drin, über das wir uns hier die Tasten locker schreiben. Nicht nur die zu verwendenden Objekte, sondern auch wie diese genau eingetragen werden. Dieses wie ist bei OSM leider, vielleicht auch bewusst, nicht durchgängig gegeben. Und so sieht jede Gegend topologisch irgendwie anders aus

Ein Auszug aus der Erläuterung zu ATKIS sagt sogar:

Im Basis-DLM werden Straßen und Wege linienförmig modelliert. Eine Straße besteht i. d. R. aus einem Straßenkörper und einer Fahrbahn. [...] Die angrenzenden Objekte aus dem Objektartenbereich „Tatsächliche Nutzung“ werden bis an die Straßenachse herangezogen.

Interessanter ist aber, dass darin sogar der von ulmtuelp benannte Fall mit dem Acker auf dem Mittelstreifen ausgeschlossen wird. Zwischen zwei getrennten Fahrspuren wird einfach eine Fläche "Straßenverkehr" eingefügt. ^^

Auch ALKIS (also ein digitales Liegenschaftskataster) definiert sehr schön die Tatsache, dass die überwiegende Nutzung der Flächen entscheidend ist. Heißt, es werden hier die Straßen und sogar die Bürgersteige als Flächen definiert, an denen unmittelbar die Nachbarfläche angrenzt. Selbst wenn man den Mehrwert der zusätzlichen Informationen zur Straßengeometrie zumindest mal ins Verhältnis des Aufnahmeaufwandes setzen sollte, ergibt es doch ein schlüssiges Bild. Hier mal ein Kuck:

Wenn man sich jetzt allerdings nachfolgende Grafik aus deinem verlinkten proposal anschaut, muss einem doch zwangsläufig die Frage kommen, welcher Mehrwert dahinter steckt, oder?

Ich meine, vielleicht ist es ein wirklich schlechtes Beispiel, aber ausnahmslos alle Linien, die den Fahrbahnrand markieren sind Parallelverschiebungen der Mittellinie. Und das ist vermutlich bei über 98% aller Wegstrecken der Fall. Warum dann nicht also "width=*" auswerten und in größeren Zoomstufen die Fahrbahn eben mit 6m Breite einzeichnen? Oder, wie gesagt, eben annehmen, dass eine Bundesstraße normiert 8m breit ist. Wo liegt da das Problem für den Renderer?
Statt einen solch lächerlich einfachen Algorithmus mit bisschen Eckenverrundung zu implementieren, sollen in Zukunft Millionen von Menschen das Straßennetz mit mind. 3 (mit zwei Gehwegen 7) nahezu identische Linien nachbilden? Und der Aufwand an Kreuzungen erst ..

Ein paar Anwendungsfälle gibts dann unbestritten aber doch: Fußgängerzonen und Innen- oder Altstädte, wo es doch einfacher ist, die häufig unförmigen Geometrien gleich mit zu übernehmen. Ich denke, das richtige Verhältnis machts.

streckenkundler · 2013-04-19 07:46:09

ronzen wrote:

Vielen Dank, streckenkundler, für deinen wirklich wertvollen Beitrag. smile Ich habe bisher noch nie etwas über dieses Anwendungsschema gehört und war sofort der Meinung, dass OSM ebenfalls so etwas braucht. Da steht ja alles drin, über das wir uns hier die Tasten locker schreiben. Nicht nur die zu verwendenden Objekte, sondern auch wie diese genau eingetragen werden. Dieses wie ist bei OSM leider, vielleicht auch bewusst, nicht durchgängig gegeben.

Da ich mit ATKIS und ALKIS dienstlich ein wenig zu tun habe, hab ich in etwa eine Vorstellung, was dahintersteckt. Wenn du dir die Datenbeschreibungen anschaust, merkst du, wie kompliziert die Objektabhängigkeiten sind. Da sehen dann nur noch sehr wenige Leute durch. Das ist etwas, was keiner von uns mit OSM machen kann und vorallem will. Mit ALKIS geht es darum die Liegenschaftskarte mit dem Kataster und dem Grundbuch zu sammenzuführen, mit all seinen Anbhängigkeiten z.B. Miteigentumsanteil, Erbbaurecht ect. Die Nutzungarten ist da eher ein Beifang und stimmen ganz gerne mal nicht. ATKIS wiederum funktioniert erst ab Maßstäben um 1:10000. Der Aubbau und und dem Zweck der beiden Geschichten ist ein völlig anderer und ich halte es für nicht möglich und gewollt, es auf OSM umzusetzen.
OSM ist anders, einfache und hat aber mehr Infos.
Bei ALKIS hast du die Vollflächigkeit und bei ATKIS die Linienhafte Generalisierung. In beiden fehlen aber Mehrwertinformationen, wie Gehwege, Fußwege, Zäune, Zugangbeschränkungen, Barrieren, ect... die wir in OSM haben und die in dieser Form bei den zwei angesprochenen A'a fehlen. Darum halte ich es für unnötig, eigentlich sogar für fatal, Informationen zu generalisieren, das dir Informationen verloren gehen.
Wofür braucht man solche Informationen: Wenn du die Entwicklung des 3D-Rendering anschaust oder die der Navigation, kann man jetzt nich nicht absehen wohin die Entwicklung geht aber je detailierter Informationen erfasst sind, desto genauer können diese angewendet und dargestellt werden. Hilfreich wäre das z.B. beim Rad- oder Fußgängerrouting für Touristen in einer kleinteilig strukturierten Stadt oder Landschaft.
Beispiel aus meiner Heimatstadt: http://www.openstreetmap.org/?lat=51.93 … 8&layers=M Ein Kreisverkehr der gerade im Bau und z.Z. teilweise bauampelgeregelt gesperrt ist, ein Parkplatz, Bootsverleih, das Strandcafe, eine große Schleuse, die Schloßinsel, das Schloß, ... alles dicht beieinander. Hier sieht man die Folgen der Generalisierung der Straßenbreiten: bei Z18 muß an der Strandcafe-Schleuse eigentlich die B87 bis an die Fußwege rechts und links davon herangeführt werden. Die Schleuse ust als solches in seiner realen Größe erfasst, mit Poller und Sperrbalken. Warum das? Es wird sicher mal ein Wasserwegerouting geben und da sind solche Dinge schon wichtig. Das kannst du nur machen, wenn du Flächen sauber in der realen Grüße erfasst und den Abstraktionsgrad (den wor ja immer noch haben) gering hältst....
Fazit für mich: keine Flächennutzungen an die Straßen heranführen, was ich auch konsequent anwende.

Sven

marek kleciak · 2013-04-19 09:06:11

Sven: +1

ronzen wrote:

vielleicht ist es ein wirklich schlechtes Beispiel, aber ausnahmslos alle Linien, die den Fahrbahnrand markieren sind Parallelverschiebungen der Mittellinie. Und das ist vermutlich bei über 98% aller Wegstrecken der Fall

Hallo Ronzen,
es ist ein schlechtes Beispiel. Sieh Dir diese Kreuzung an: http://osm.org/go/0JBK8xZo2--

Viele Grüße,
Marek

S-Man42 · 2013-04-19 10:00:36

Oder diese (die Hölle für alle Beteiligten...)
http://osm.org/go/0JBK80PFy--
oder diese
http://osm.org/go/0MbFw8nSp--

Es ist nach wie vor so, dass du Flächen verfälscht, indem du eine Abstraktion annimmst, die nicht allgemeingültig ist. Je detaillierter du alles erfasst, desto mehr Möglichkeiten der Auswertung hast du. Und du kannst dann gern auch abstrahierte Karten rendern, wenn du lustig bist...

marek kleciak · 2013-04-19 10:13:24

Hallo S-Man42:
http://osm.org/go/0MbFw8nSp--
bist Du dort zu Hause? Hat Bing an dieser Stelle Verschiebung?

1. "Es ist nach wie vor so, dass du Flächen verfälscht, indem du eine Abstraktion annimmst, die nicht allgemeingültig ist." -> Daher streben wir eine gemeinsame Lösung / Taggingschema an. Ein Beispiel wie http://osm.org/go/0JBK80PFy-- ist eine Diskussionsgrundlage ansonsten reden wir ins Leere.

2. "Je detaillierter du alles erfasst, desto mehr Möglichkeiten der Auswertung hast du."
-> Jajn. Steht erst mal ein Schema ist es die Entscheidung der User wie sie an einer solchen Stelle vorgehen.

Zu diesem Schema schrieb ich schon hier: http://wiki.openstreetmap.org/wiki/File … legend.jpg

Grüße,
Marek

Last edited by marek kleciak (2013-04-19 10:13:37)

S-Man42 · 2013-04-19 12:22:56

Nein, dort wohne ich nicht, aber ich kenne die Ecke ziemlich gut. Ob Bing da eine Verschiebung hat, kann ich leider nicht sagen. Habe von dort keine eigenen GPS Tracks...

1.) Sehe ich auch so.
2.) Richtig, aber darum ging es ja im Moment nicht. Aktuell ist es ein "wie macht man das aktuell" und da gibt es eben unterschiedliche Meinungen. Mehr nicht Und ich habe eben nur meine Meinung begründet und warum mir aus meiner Sicht seine passt.

Ja, ich kenne deine Straßenflächen-Sachen Habe ich mit INteresse verfolgt. Da dazu aber schon andere viel qualifiziertere Aussagen gemacht haben, als ich dazu im Stande bin, halte ich mich zu dem Thema dezent zurück und warte auf den Konsens... (also ewig ). Fakt ist aber, dass alle Proposals in Straßen-Flächen endeten. Und damit sind wir wieder am Anfang - nämlich, dass ich ronzens Meinung nicht mag

marek kleciak · 2013-04-19 13:21:34

Nun,
wie wir schon mal (Konsens) gesagt haben: Wir brauchen einen Renderer, der die Straßenflächen unterstützt. Sonst wir es ja auch keinen Spaß machen.

Beste Grüße!
Marek

GeorgFausB · 2013-04-19 13:49:21

Moin,

ronzen wrote:

Ich meine, vielleicht ist es ein wirklich schlechtes Beispiel, aber ausnahmslos alle Linien, die den Fahrbahnrand markieren sind Parallelverschiebungen der Mittellinie. Und das ist vermutlich bei über 98% aller Wegstrecken der Fall. Warum dann nicht also "width=*" auswerten und in größeren Zoomstufen die Fahrbahn eben mit 6m Breite einzeichnen? Oder, wie gesagt, eben annehmen, dass eine Bundesstraße normiert 8m breit ist. Wo liegt da das Problem für den Renderer?
Statt einen solch lächerlich einfachen Algorithmus mit bisschen Eckenverrundung zu implementieren, sollen in Zukunft Millionen von Menschen das Straßennetz mit mind. 3 (mit zwei Gehwegen 7) nahezu identische Linien nachbilden? Und der Aufwand an Kreuzungen erst ..
Ein paar Anwendungsfälle gibts dann unbestritten aber doch: Fußgängerzonen und Innen- oder Altstädte, wo es doch einfacher ist, die häufig unförmigen Geometrien gleich mit zu übernehmen. Ich denke, das richtige Verhältnis machts.

Bisher war es bei OSM eigentlich immer so:
1) Wer zuerst kommt, macht es wie er meint.
2) Nachfolgende können es verfeinern.
3) Vorgefundene Detailinformationen werden aber nicht wieder "vereinfacht".

Eine feste Vorgabe auf ATKIS-like lässt sich nicht durchsetzen, wenn es welche gibt, die - z. B. im Ortsbereich - ALKIS-like möchten/benötigen.
Es wird dich keiner dazu verdonnern können, die Grunderfassung ALKIS-like durchführen zu müssen.
Du wirst aber damit leben müssen, vorhandene ALKIS-like Erfassung bestehen lassen zu müssen.
Und es wäre nett, wenn Du Deine Arbeitsweise dort anpassen würdest.
Aber es kann Dir nicht mal einer an den Karren fahren, wenn Du korrekte Lage-Änderungen machst und nur dort dann Deine Arbeitsweise anwendest ... da kommt dann halt wieder 2) zum Tragen.

Bis die ALKIS-Erfassung sich jemals flächendeckend durchsetzt, vergehen noch Jahre.
Und dort, wo großflächig eine "formelmäßige Auswertung" möglich ist (Überland), wird sich wahrscheinlich auch solch ein Verfahren durchsetzen.

Gruß
Georg

Announcement

#51 2013-04-18 12:37:46

Re: Müssen alle Zwischenräume mit Flächen gefüllt sein?

#52 2013-04-18 13:36:39

Re: Müssen alle Zwischenräume mit Flächen gefüllt sein?

#53 2013-04-18 13:45:11

Re: Müssen alle Zwischenräume mit Flächen gefüllt sein?

#54 2013-04-18 13:53:56

Re: Müssen alle Zwischenräume mit Flächen gefüllt sein?

#55 2013-04-18 16:04:39

Re: Müssen alle Zwischenräume mit Flächen gefüllt sein?

#56 2013-04-18 16:15:13

Re: Müssen alle Zwischenräume mit Flächen gefüllt sein?

#57 2013-04-18 16:16:09

Re: Müssen alle Zwischenräume mit Flächen gefüllt sein?

#58 2013-04-18 16:39:01

Re: Müssen alle Zwischenräume mit Flächen gefüllt sein?

#59 2013-04-18 16:39:15

Re: Müssen alle Zwischenräume mit Flächen gefüllt sein?

#60 2013-04-18 17:17:27

Re: Müssen alle Zwischenräume mit Flächen gefüllt sein?

#61 2013-04-19 00:48:25

Re: Müssen alle Zwischenräume mit Flächen gefüllt sein?

#62 2013-04-19 07:46:09

Re: Müssen alle Zwischenräume mit Flächen gefüllt sein?

#63 2013-04-19 09:06:11

Re: Müssen alle Zwischenräume mit Flächen gefüllt sein?

#64 2013-04-19 10:00:36

Re: Müssen alle Zwischenräume mit Flächen gefüllt sein?

#65 2013-04-19 10:13:24

Re: Müssen alle Zwischenräume mit Flächen gefüllt sein?

#66 2013-04-19 12:22:56

Re: Müssen alle Zwischenräume mit Flächen gefüllt sein?

#67 2013-04-19 13:21:34

Re: Müssen alle Zwischenräume mit Flächen gefüllt sein?

#68 2013-04-19 13:49:21

Re: Müssen alle Zwischenräume mit Flächen gefüllt sein?

Board footer