Angrenzende Landuses Abbilden

TheFive · 2013-09-13 17:34:51

Dann versuche ich mal zusammenzufassen.

Angrenzende landuses können über shared nodes implementiert werden.

Liegt zwischen den Landuses eine Strasse, so sollte diese nicht mit integriert werden, da dies die Wartbarkeit für andere Mapper verringert, damit auch gleich eine überflüssige Fehlerquelle ist.

Im Falle von Grenzen sollten diese keine share nodes mit den landuses (oder Seen oder Bachläufen...) haben, sofern diese Grenzen geografisch FIX sind. Mögliche seltene Ausnahmen werden im Thread beschrieben.

Von einer Lösung über shared ways und Multipolygone sollte eher Abstand genommen werden.

Werkzeuge in JOSM um entsprechende shared nodes zu bearbeiten sind:

Punkte Vereinigen (aus 2 oder mehr mach 1nen) und
Linien Trennen (erzeuge für alle gemeinsamen Nodes zweier Linien separate notes, damit diese anschießend separat zu bearbeiten sind)
Selektion: Im Bereich der gemeinsam genutzten nodes können die Linien durch hintereinander (unter Zuhilfenahme der passenden Taste) anklicken, oder mit der mittleren Maustaste (sofern man keinen Mac hat) selektiert werden.

TheFive · 2013-09-13 17:48:48

Franz:

Deine Fragen möchte ich auch nicht unbeantwortet lassen.

a) Abstraktion

Abstraktion ist das was wir machen. Wir bilden die komplexe Wirklichkeit mit Punkten und Linien ab. Schön wäre für mich, das dann Gegebenheiten wie
Dieses Landuse grenzt an X (Landuse oder Highway) gleich abgebildet werden. Das hiesse aber, das landuses und highways auch über shared nodes abzubilden wären, was die Wartbarkeitsnachteile hat.

b) Professionalität

Ich finde es schön, wenn die gerenderte Karte im höchsten Zoomlevel nicht kleine weisse undefinierte Flächen zwischen den Landuses und den Highways hat. Das hab ich am Weissensee in Kärnten mit GoMap noch nicht erreicht.

c) Multipolygonlösung.

xxxxxizzzzz
x    i    z
x  A i B  z
x    i    z
xxxxxizzzzz

3 Linien x i und z werden genutzt um die Flächen A und B zu zeichnen.

1 Multipolygon A hat als Outer x und i
1 Multypolygon B hat als outer Z und i

Damit gibt es keinen doppelten Weg auf der Linie i. Allerdings werden damit die Linien auf den "Kleinsten Gemeinsamen Nenner" gesplittet, was ein Wust von outer ways in den ensprechenden Multipolygonen gibt.

pyram · 2013-09-13 19:33:33

streckenkundler wrote:

wambacher wrote:
Heute ist die Grenze fest als solche im Kataster erfasst und wenn der Bach "meandert", ändert sich rechtlich nichts mehr.
das stimmt so nicht.

Das ist doch für uns egal, wo eine rechtliche Grenze verläuft. Entscheidend ist, wo das Wasser ist und wo das Gras wächst ;-)

rayquaza · 2013-09-13 19:36:39

Für die Erfassung der Grenzen ist uns das aber nicht egal, und wenn die Ways gemeinsame Knoten haben würden die dann jeweils mit verschoben wenn man nicht sehr gut (etwas unrealistisch gut) aufpasst.

pyram · 2013-09-14 00:44:05

rayquaza wrote:

Für die Erfassung der Grenzen ist uns das aber nicht egal

Da missverstehst Du mich aber. Ich meinte, dass es doch egal ist, ob sich die Katastergrenze der Wiese durch Lageveränderung des Baches verändert oder nicht, weil wir Katastergrenzen nicht sehen können und daher nicht mappen.
Wambacher hat die Anmerkung von chris66 meiner Meinung nach falsch interpretiert: Es war von der physikalischen gemeinsamen Grenze und nicht von der katastertechnischen Grenze die Rede.
Ich bin ansonsten vollkommen der Meinung von chris66. Flächen, die mit Linien abstrahiert werden (Straßen), sollten nicht ohne Grund mit Flächen, die als Flächen erfasst werden verbunden werden (das sind eigentlich zwei verschiedene Philosophieen). Ansonsten müssten auch Straßen als Flächen erfasst werden (was teilweise gemacht wird (Fußgängerzonen) - und dann zu den bekannten Problemen (bedingt routingfähig) führt). Die Lösung muss dann sinngemäß wie bei Waterway/Riverbank aussehen. Bei Flüssen, wie der Donau würde ja auch (hoffentlich) keiner auf die Idee kommen, die angrenzenden landuses bei fehlendem Riverbank an den Waterway zu hängen, nur damit die Karte "schön" aussieht.

ulmtuelp · 2013-09-14 13:41:22

TheFive wrote:

Ich finde es schön, wenn die gerenderte Karte im höchsten Zoomlevel nicht kleine weisse undefinierte Flächen zwischen den Landuses und den Highways hat.

Meiner Meinung sind die doch definiert, d.h. wo keine extra Angabe steht handelt es sich um: Landfläche. Nur die genaue Attributierung ist nicht angegeben.
Oder?

EvanE · 2013-09-14 14:04:35

ulmtuelp wrote:

TheFive wrote:
Ich finde es schön, wenn die gerenderte Karte im höchsten Zoomlevel nicht kleine weisse undefinierte Flächen zwischen den Landuses und den Highways hat.
Meiner Meinung sind die doch definiert, d.h. wo keine extra Angabe steht handelt es sich um: Landfläche. Nur die genaue Attributierung ist nicht angegeben.
Oder?

Insbesondere handelt es sich um die Fläche, die für die Straße und eventuelle Straßenergänzungen wie Bankette, Straßengrün, Gräben usw. benötigt wird.

Das ist bei OSM übrigens ein reines Luxus-Problem. Papierkarten gibt es wohl kaum in so hoher Auflösung. Andere Onlinekarten ohne OSM-Datengrundlage haben meist keine Landflächen.

Mit dem relativ neuen Zoomlevel 19 wird das Problem nochmal verschärft.
Aber noch einmal: Wir versuchen die Realität abzubilden. Das heißt insbesondere, dass der Wald, der Acker oder die Wiese spätestens am Straßenrand endet. Ob das in der maximalen Zoomstufe eines Renderers dann eventuell bescheiden aussieht, sollte kein Kriterium sein.

JM2C
Edbert (EvanE)

Thomas8122 · 2013-09-14 14:15:47

EvanE wrote:

Ob das in der maximalen Zoomstufe eines Renderers dann eventuell bescheiden aussieht, sollte kein Kriterium sein.

Exactomundo

toc-rox · 2013-09-14 16:14:35

Thomas8122 wrote:

EvanE wrote:
Ob das in der maximalen Zoomstufe eines Renderers dann eventuell bescheiden aussieht, sollte kein Kriterium sein.
Exactomundo

Nein, das sehe ich nicht so ... denn wenn man die Realität betrachtet (und mappt), gibt es da irgendwie keine "weissen Lücken".

Gruß Klaus

rayquaza · 2013-09-14 16:19:13

toc-rox wrote:

denn wenn man die Realität betrachtet (und mappt), gibt es da irgendwie keine "weissen Lücken".

Richtig, aber an den Stellen an denen keine "weisse Lücke" ist ist auch nicht das, was nebendran ist

TheFive · 2013-09-14 16:27:38

Ja ja, die Bankette :-)

Die einzigen OSM Daten wo ich die bisher gesehen habe war im Forum.

Abstraktion ist auch weglassen, genau wie wir ja auch die Bahnschwellen weglassen. (noch mindestens 4 Jahre, für länger möchte ich mich da nicht festlegen.).

Und was die weissen Flächen angeht bin ich bestimmt gerade in der "Wir mappen doch ein bischen für die Renderer" Falle.

Chrisotph

rayquaza · 2013-09-14 16:35:54

TheFive wrote:

Ja ja, die Bankette :-)

Das musste ich jetzt nachschlagen. Faszinierend, wie viel man zu so einem bisschen Grün schreiben kann.

TheFive wrote:

[…] genau wie wir ja auch die Bahnschwellen weglassen. (noch mindestens 4 Jahre, für länger möchte ich mich da nicht festlegen.).

OT: Schwellen mappen wäre zumindest sinnvoller als Schienen mappen

seichter · 2013-09-14 19:52:17

rayquaza wrote:

toc-rox wrote:
denn wenn man die Realität betrachtet (und mappt), gibt es da irgendwie keine "weissen Lücken".
Richtig, aber an den Stellen an denen keine "weisse Lücke" ist ist auch nicht das, was nebendran ist

Da bin ich schon auf die ersten Versuche gestoßen (Häfnerhaslach), die letzten weißen Flächen auf der Karte von D zu beseitigen:
Eine area:highway im Prinzip ähnlich zum Verfahren bei riverbank mit gemeinsamer Begrenzung zu Wald und Wiese.
Asphalt, Bankett und Straßengraben sind (noch?) nicht getrennt erfasst.

derandi · 2013-09-15 17:55:03

Hallo,

ich bin aus diesen User http://www.openstreetmap.org/user/geokyf/edits gestoßen. Er nutzt MP für alles und baut unötige Kontruktionen.
Als Bsp.
http://www.openstreetmap.org/browse/changeset/17562030

Am besten im Editor betrachten.

vg

TheFive · 2013-09-15 18:53:51

derandi wrote:

http://www.openstreetmap.org/browse/changeset/17562030

Hallo Franz:

Das sieht nach einem exakten Anwendung meines C Falles aus.

at derandi,

bei der oberflächlichen Kontrolle kann ich keinen Fehler erkennen.
Ist eine Frage des Stils da ist unsere Map OPEN.

Hier im Thread war zwar der Grund Tenor, das die einfacher zu editierende Variante Shared Nodes sind, aber eben nur hier im Thread.

Ich frage mich aber nach dem 2 Tägigen wieder reinschnuppern hier im Forum, ob es nicht eine grundlegendere Lösung hier bedarf.

Durch die Detaillierung steigen die Datenmengen.
a) Bing liefert bessere Daten
b) 3 D Mapping
c) Da die Grundelemente Erfasst sind, wenden sich die Mapper den weiteren Möglichkeiten zu.

Das sorgt für etliche Punkte auf einen Haufen, die Newbees nachvollziehbar vor Probleme setzen.
(Als ich angefangen habe, habe ich fehlende Strassen eingezeichnet, später sind Radwege dazugekommen, jetzt sind an jeder Grösseren Strasse 1 Radweg, ein Landuse, 1 Highway und die Gebäude, die dann irgendwann mit mehreren Stockwerken.).

Die erste lösung wären einfache Filter (so hab ich z.B. immer alle Boundaries rausgefiltert (JOSM)).

Das man ID und Potlatch einfach Dinge wie Landuses, Boundaries.. rausfiltern kann, würde eventuell schon helfen.

Müssen wir eigentlich alle Daten in eine Datenmenge packen ? Kann das API die nicht gleich trennen in Natural, Manmade, und beim Laden gibt man an, was man laden will, beim Speichern wird das D für Disconnect geprüft ?

Nadjita · 2013-09-15 19:23:26

TheFive wrote:

Die erste lösung wären einfache Filter (so hab ich z.B. immer alle Boundaries rausgefiltert (JOSM)).

Das waere - ungeachtet der eigentlichen Themas dieses Threads - wirklich wuenschenswert. Selektiv nur landuses, naturals, buildings, highways/paths einblenden koennen mit einem Click: das wuerde mir bei der alltaeglichen Arbeit extrem helfen. Manchmal ist weniger eben mehr.

Pfad-Finder · 2013-09-15 20:03:22

TheFive wrote:

bei der oberflächlichen Kontrolle kann ich keinen Fehler erkennen.
Ist eine Frage des Stils da ist unsere Map OPEN.

"Fehler" nicht, aber manches erscheint mit Verlaub absolut unnötig und auch unsinnig:

http://www.openstreetmap.org/browse/relation/3170443

Die drei nördlichen Flächen bestehen aus normalen geschlossenen Ways und sind zu einer Outers-Relation zusammengefasst, ohne das es es Inners gibt? So was hat nicht mal der User M....k aus der Oberlausitz gebracht.

Da die Relation seit dem 28.8. nicht mehr angefasst wurde, kommt die Ausrede "Work in Progress" wohl nicht in Frage.

TheFive · 2013-09-15 20:13:17

Pfad-Finder wrote:

"Fehler" nicht, aber manches erscheint mit Verlaub absolut unnötig und auch unsinnig:

Na Ja, der Bauer dem die 3 Felder gehört hat seinen Namen nicht für die ODBL Freigegeben.
Das wäre doch ein Grund für die Zusammenfassung ohne weiter sinnvolle Tags auf der multipolygon ebene.

Eine gewisse Akribie kann ich dem Kollegen nicht absprechen. Eine Fläche die bei mir 4 Nodes bekommt, mapt er mit
32.

Christoph

TheFive · 2013-09-15 20:23:54

btw, wo ich einmal dabei bin, ist mir natürlich vom kleinen Urlaubsort aus ein Riesen Polygon über den Weg gelaufen (ein Wald und derer gibts bei den Österreichern grosse).

Ist es im Sinne der Editierbarkeit eigentlich legitim eine Waldfläche ohne Namen zu splitten in handhabbare kleinere MPs ?

Christoph

rayquaza · 2013-09-15 20:34:26

TheFive wrote:

Na Ja, der Bauer dem die 3 Felder gehört hat seinen Namen nicht für die ODBL Freigegeben.
Das wäre doch ein Grund für die Zusammenfassung ohne weiter sinnvolle Tags auf der multipolygon ebene.

Ich bezweifle, dass soetwas der Grund dafür ist. Und selbst wenn könnte man es als einfache Flächen lassen wenn man es eh nicht einträgt (davon abgesehen, dass sich auch das ohne Multipolygon lösen liesse).

TheFive wrote:

Eine gewisse Akribie kann ich dem Kollegen nicht absprechen. Eine Fläche die bei mir 4 Nodes bekommt, mapt er mit
32.

Das Problem hier ist nicht "Atom-genaues Mappen" vs. "schnell mal hingekritzelt" sondern "unnötig kompliziert" vs. "so einfach wie möglich, so kompliziert wie nötig". Bei letzterem ist übrigens letzteres die "Datentechnisch sauberere Abbildung" (was auch immer genau ihr damit meint).

TheFive wrote:

Ist es im Sinne der Editierbarkeit eigentlich legitim eine Waldfläche ohne Namen zu splitten in handhabbare kleinere MPs ?

Ja, du darfst sogar Waldflächen mit Namen aufteilen, wenn du es richtig machst (ich kenne mich damit nicht aus, aber das geht bestimmt). Und du darfst es sogar in einfache Polygone aufteilen falls das sinnvoll möglich ist

TheFive · 2013-09-15 20:48:12

Ich gebe die 100 %tig recht. Kompliziert ist doof.

Nur eine formale "Handhabe" der Art "Du machst das Falsch" ist nicht gegeben.
Allerdings spricht nix dagegen, den Kollegen freundlich auf eine überflüssige Kompliziertheit aufmerksam zu machen.
Immerhin gibt es einen guten Grund, OSM Lebt nur, solange es Mapper gibt, die die Daten verstehen.

---------

Nachdem ich gerade überlegt habe ein MP zu splitten ist mir aufgefallen, das das durchaus aufwendig sein kann.

Einen Weg kann JOSM Splitten, aber ein MP nicht. Alle Inner und Outer müssen dann ja richtig zugeordnet werden. Das übt ....

streckenkundler · 2013-09-15 21:20:24

rayquaza wrote:

Ja, du darfst sogar Waldflächen mit Namen aufteilen,

Vor allem, wenn es einem nötig erscheit, sollte man es tun!!! Viele Nutzer verbinden einen Namen eines Waldgebietes damit, daß diese Fläche dann auch als Polygon/ Multipolygon zusammen zubleiben hat.
Diese Ansicht ist in meinen Augen Falsch. Die Verwendung von Polygonen/ Multipolygonen (so man sie denn so in OSM Nennen möge) sollte zunächst allein der räumlichen Natur der Verteiung der Objekte erfolgen (und nur dieser?!!) und nicht als erstes des Inhaltes. OSM bietet genühend Möglichkeiten, Räumliche und inhaltliche Beziehungen zu verbinden (Relationen!).

Grundtenor sollte sein: "So einfach wie möglich." Eine Erfassung eines Objektes als (komplexe) Relation, daß auch als einfaches Objekt erfasst werden kann, ist keine einfache Erfassung. Ich verweise hier auf: http://forum.openstreetmap.org/viewtopic.php?id=22490.

Das heist für mich im Allgemeinen *): bei Flächen möglichtst geschlossene Linienzüge zu verwenden, bei Objekten, die als einfache gechlossene Linienzügen dargestellt werden können, sind diese als einfache Linienzüge darzustellen. Relationen sind nur wenn nötig zu verwenden und möglichst als Relation von geschlossenen Linienobjekten. Es gibt keine taglosen Objekte in Relationen.

*): Administrative Grenzen zähle ich nicht dazu.

Sven

EvanE · 2013-09-15 21:51:43

TheFive wrote:

Nachdem ich gerade überlegt habe ein MP zu splitten ist mir aufgefallen, das das durchaus aufwendig sein kann.
Einen Weg kann JOSM Splitten, aber ein MP nicht. Alle Inner und Outer müssen dann ja richtig zugeordnet werden. Das übt ....

Ja da ist Handarbeit angesagt.
Der Validator erkennt aber falsche Inner, die nach dem Aufteilen nicht mehr innerhalb eines Outer liegen. So bleiben einem einige Fehler erspart. Voraussetzung ist natürlich, dass das MP komplett geladen ist. Sonst wäre zu wenig zum Prüfen vorhanden.

Edbert (EvanE)

pyram · 2013-09-15 22:09:22

toc-rox wrote:

Thomas8122 wrote:
EvanE wrote:
Ob das in der maximalen Zoomstufe eines Renderers dann eventuell bescheiden aussieht, sollte kein Kriterium sein.
Exactomundo
Nein, das sehe ich nicht so ... denn wenn man die Realität betrachtet (und mappt), gibt es da irgendwie keine "weissen Lücken".

Wenn es da weiße Lücken gibt, könnte das auch bedeuten, dass der Renderer die Straße zu schmal zeichnet ;-)

***Ironie ein*** Ansonsten ist in der Realität der Streifen zwischen dem Acker und der Straße in D meistens grün/grau. Ich glaube, da hilft nur, dass die Standardkarte einen grünen (und im Winter weißen) Hintergrund zeigt. ***Ironie aus***

peb12345 · 2013-09-15 22:51:52

Pfad-Finder wrote:

"Fehler" nicht, aber manches erscheint mit Verlaub absolut unnötig und auch unsinnig:
Die drei nördlichen Flächen bestehen aus normalen geschlossenen Ways und sind zu einer Outers-Relation zusammengefasst, ohne das es es Inners gibt? So was hat nicht mal der User M....k aus der Oberlausitz gebracht.

Wenn M...k der User ist der in Ostdeutschland nach dem Lizenzwechsel wegen nicht Zustimmung
große Lücken hinterließ: Jener der ich meine IST in neuer Inkarnation geokyf. Zumindest schrieb
das letzterer mal, weis aber nicht mehr wo, ist länger her. Von der manischen mapping Menge passt es.

Ansonsten bin ich gegen MP. Die sollte man nur nutzen wo es unumgänglich ist.
Die Dinger sind unwartbar[1]. Bei sowas wie Grenzen ist es gut. Shared Nodes haben
ihre Probleme, sind meist ok. Shared ways (MP) sind da noch mal eine Kategorie
problematischer.

Aber ich hab' gerade keine Zeit weiter aktiv gegen MP zu arbeiten:-)

[1] Da meine ich in erster Linie die mit vielen outer Wegstückchen die auch noch
in vielen weiteren MP genutzt werden. Ein außen geschlossenes Polygon das
paar inner hat geht ja noch. Aber auch die scheinen öfter nicht so nötig: steht man
auf einer Lichtung im Wald und wird angerufen, sagt man da nicht 'Bin gerade im Wald'?
Die Lichtung ist also teil vom Wald, stehen aber halt keine Bäume (landuse vs. landcover?)
Das Problem wird da: ab welcher Größe wird die Lichtung zur großen Wiese, zum Tal?

Announcement

#26 2013-09-13 17:34:51

Re: Angrenzende Landuses Abbilden

#27 2013-09-13 17:48:48

Re: Angrenzende Landuses Abbilden

#28 2013-09-13 19:33:33

Re: Angrenzende Landuses Abbilden

#29 2013-09-13 19:36:39

Re: Angrenzende Landuses Abbilden

#30 2013-09-14 00:44:05

Re: Angrenzende Landuses Abbilden

#31 2013-09-14 13:41:22

Re: Angrenzende Landuses Abbilden

#32 2013-09-14 14:04:35

Re: Angrenzende Landuses Abbilden

#33 2013-09-14 14:15:47

Re: Angrenzende Landuses Abbilden

#34 2013-09-14 16:14:35

Re: Angrenzende Landuses Abbilden

#35 2013-09-14 16:19:13

Re: Angrenzende Landuses Abbilden

#36 2013-09-14 16:27:38

Re: Angrenzende Landuses Abbilden

#37 2013-09-14 16:35:54

Re: Angrenzende Landuses Abbilden

#38 2013-09-14 19:52:17

Re: Angrenzende Landuses Abbilden

#39 2013-09-15 17:55:03

Re: Angrenzende Landuses Abbilden

#40 2013-09-15 18:53:51

Re: Angrenzende Landuses Abbilden

#41 2013-09-15 19:23:26

Re: Angrenzende Landuses Abbilden

#42 2013-09-15 20:03:22

Re: Angrenzende Landuses Abbilden

#43 2013-09-15 20:13:17

Re: Angrenzende Landuses Abbilden

#44 2013-09-15 20:23:54

Re: Angrenzende Landuses Abbilden

#45 2013-09-15 20:34:26

Re: Angrenzende Landuses Abbilden

#46 2013-09-15 20:48:12

Re: Angrenzende Landuses Abbilden

#47 2013-09-15 21:20:24

Re: Angrenzende Landuses Abbilden

#48 2013-09-15 21:51:43

Re: Angrenzende Landuses Abbilden

#49 2013-09-15 22:09:22

Re: Angrenzende Landuses Abbilden

#50 2013-09-15 22:51:52

Re: Angrenzende Landuses Abbilden

Board footer