Hi Martin, Als Ursache für diese Konflikte sehe ich folgende Ursachen: a) die einen wollen "hübsche" Karten (nahtlos), die anderen wollen unaufwändig verbessern können b) Missverständnisse aus Begriffsverwirrung (unklare Definitionen)
Wenn man "hübsch" will, sind gemeinsame Punkte wesentlich. Wenn man iterative Verbesserung will, ist "unaufwändig verbessern können" wesentlich. Da in niedrigen Zoomleveln kein Unterschied erkennbar ist, und Lage und Form nur in hohen Zoomleveln verbesserbar sind, würde ich der Verbesserung höhere Priorität einräumen. Und das mit den Missverständnissen - da müssen wir halt noch viel präzisere und verständliche nachvollziehbare Beschreibungen schaffen. > Spundwand (Vertikale, feste, gebaute Uferbefestigung), > die begrenzt die Wasserfläche, Ja, aber nur von oben (Senkrechtbild) betrachtet. Im Aufriss liegt die Wiese je nach Wasserstand deutlich über dem Wasser und getrennt davon, oder das Wasser bedeckt die Wiese. Nur im seltenen Spezialfall stossen beide aneinander. Wen nun in Florians Beispiel die "Kühe Wasser trinken", dann stehen sie entweder im Überschwemmungsgebiet, oder sie haben sich am Ufer einen Schlammhang gebaut, über den sie bis zum Wasser runterlaufen, oder sie haben zu Giraffen mutiert ;-) Das mit den Schlammlöchern ist häufig. Dan hilft es aber sehr, wenn man beim Nacharbeiten einfach die Wiese etwas wegziehen, und die Lücke passend taggen kann. > zwischen ihr und dem Wasser noch eine Spalt freizulassen wäre "falsch". "richtig" wäre, wenn die Punkte "virtuell aufeinanderliegen", datentechnisch (und im Renderer) nicht verbunden wären. Damit es virtuell "keine Lücken" gibt, aber man das Fehlende unkompliziert real "in die Lücke einfügen" kann ;-) > bei fließenden Übergängen ist die Sache unklar, auch wie man es am besten > mappen soll, ich würde mich in der Diskussion hier zunächst auf die klaren > Fälle beschränken, wo die Grenzen klar erkennbar sind Einverstanden. Aber dazu muss man gaanz genau definieren und erklären. Alternativ könnte man regeln: "keine gemeinsame Knoten". Und es dem Renderer überlassen, wie er mit "virtuellen Lücken" umgeht. > weil es auch dort unterschiedliche Meinungen gibt, > wie man es abbilden will Das liegt meist daran, dass jeder unter "es" etwas anderes versteht: > es sollte dort zumindest klar sein, was es ist, das man abbilden will Das erfordert noch sehr viele erklärende konkrete Best-Practice- Beispiele im Wiki! > (das Datenmodell erlaubt es von sich aus, klare Grenzen klar zu zeichnen). Das Datenmodell erlaubt /ausschliesslich/ klare Grenzen. Und solange es keine Darstellungsmethode für Diffuses gibt, bleibt vermutlich ein systematisches unlösbares Problem. (s. Spundwand, dort 3D-Prolem) >> Friedhof der ohne Straße dazwischen an ein Wohngrundstück angrenzt >>> (Grenzmauer zwischen den beiden, typischerweise) >> >> Jeder weiss, was ein "Friedhof" ist. >> Aber was ist das datentechnisch genau? >> - alles innerhalb der Gemarkungsgrenze? > > falls das "Parzellengrenze" heissen sollte, nein (s.u.) Die hierzulande im Grundbuch eingetragene Friedhofsgrenze. >> - alles innerhalb der Aussenkante der Friedhofsmauer? > > das ist vermutlich kulturell unterschiedlich, bei christlichen Friedhöfen > gibt es normalerweise (ja, gibt Ausnahmen), eine Mauer und das wäre für > mich die klare Grenze. Wenn ein Friedhof noch einen Parkplatz davor hat > (grundstückstechnisch), würde ich den eher nicht zum Friedhof schlagen > sondern für sich mappen. Dann sollte das so im Wiki stehen. Ebenfalls für Friedhofskapelle, Aussegnungshalle, Toiletten, Kompostlagerplatz, Friedhofsgärtnerei/-Blumenhandlung, etc. Und natürlich: was wann wie mit was verbunden sein soll oder nicht - und warum in welchem Fall ;-) Die Mauer müsste schon sehr dick sein, dass Innen- > und Aussengrenze verschiedene Objekte wären. > Z.B. gibt es hier einen Friedhof an der Stadtmauer, das ist bisher immer > noch die Mauer als nur eine Linie gemappt (könnte man aber zugegebenermaßen > bei Gelegenheit mal nachholen): https://www.openstreetmap.org/way/24575663 Ja, da fehlt noch Vieles im und um den Friedhof ;-) >> - was ist, wenn die Friedhofsmauer (teilweise) gleichzeitig die >> Stadtmauer ist? was gehört dann zu "residental" bzw. "graveyard"? > > alles bis Innenkante Stadtmauer würde ich sagen, ausser in der Mauer ist > auch noch Begräbnisstätte. Das meine ich mit "Genauigkeit in der Beschreibung": ich meinte, der Friedhof ist aussen die Stadt ist innerhalb der gemeinsamen Mauer (hatte ich aber nicht dazugeschrieben). Du meintest vermutlich: dass beides innerhalb der Stadtmauer ist? Und Gräber (oder Urnen) /in/ der Mauer machen sowieso alles noch schwieriger. >> - wann liegt der Friedhof "im Wald"? >> wann liegt der Wald "im Friedhof"? >> wann sind es gleichrangige Objekte? > > ist z.B. eine Frage der Größen Nein, das ist eine Frage der Definition: > jedenfalls kann das mit unseren Daten jeder für sich entscheiden. Dabei legt er (s)eine Definition zugrunde, legt sie aber (meist) nicht offen. - Und schon haben wir die Basis für Missverständnisse und Konflikte ;-) >> - alles innerhalb das für Gräber vorgesehen ist? >> (also nicht der Wald, nicht die Gebäude, nicht der Teich) >> - nur die für Gräber vorgesehene Fläche (ohne Zufahrtswege)? >> - nur die für Gräber vorgesehene Fläche (ohne alle Wege)? >> - nur die für Gräber aktuell genutzte Fläche? > > nein Dann muss das genau so ins Wiki :-) (sonst wird das - und anderes - noch ewig diskutiert) >>> 2 Gebäude die angebaut sind > > gemeint war, dass es 2 Gebäude gibt, deren jeweilige Aussenwände sich > berühren, bzw. scheinbar berühren (1 Zentimeter Luft dazwischen oder so > gilt auch noch). Dazu sagt man auch "angebaut" Die am Haus L-förmig angebaute Garage - wann ist das nun: - ein Haus mit einem Umriss und 7 Punkten - ein Haus mit einem Umriss und Trennwand, insgesamt 7 Punkten - zwei Häuser mit insgesamt 7 Punkten, 2 davon verbunden - zwei Häuser mit je 4 Punkten Und was ändert sich, wenn später über der Garage ein Dachgeschoss gebaut und dieses mit dem Haupthaus integrierend verbunden wird. (Ok, das sind jetzt eher architektonische Fragen. Wenn es aber schon hier bei gleichen Objekten nicht so einfach ist, dann zeigt das, wie schwierig es bei Objekten unterschiedlicher Klasse wird...) > wir werden sowieso kaum in die Lage kommen, in solchen historischen > Innenstädten die Details zu kartieren/vermessen. ;-) > ja, das sind unterschiedliche Dinge, aber es ändert nichts daran dass ihre > Geometrie voneinander abhängt: die Gebäudekante ist gleichzeitig die > Platzkante. Das ist dieselbe Linie. Dazwischen ist nichts. Je nachdem... Es gibt Häuser, deren Dach über den Platzrand ragt, aber die Autos trotzdem bis zur Hauswand parken dürfen. Andere haben einen "Vorgarten". Und manchmal ist das kaum unterscheidbar ;-) >> Interessante Frage! >> (wer definiert was genau und wie als "Realität"? und wie mappen wir >> unterschiedliche Definitionen?) > > was ich meine: unsere Straße wird meist nicht genau mit der Straße der > Vermessungsämter deckungsgleich sein, die Grenzen die wir importieren > basieren aber normalerweise schlussendlich irgendwie auf Daten der > Vermessungsämter. Die bessere Grenze für uns wäre Auch da bräuchte man eine Definition (i.S.v. Best-Practice) wann welche Realität - und vor allem: warum genau? - wie zu berücksichtigen ist. (sonst ist das ein weiterer Grund für endlose OSM-interne Spiegelgefechte) >>> Wenn die Grenzbschreibungen dagegen über andere Objekte definiert sind, >>> dann sollten sie auch in OSM über diese abgebildet werden. >> >> Da wir weder Flüsse noch Grate genau abbilden, würde ich auch in diesem >> Fall für die Grenzen eigene Linien malen. > > wenn der Fluss die Grenze _ist_, dann ist das auch die Genauigkeit. > Wenn der Fluss seine Lage ändert, hat das auch Einfluss auf die Grenze? Das kommt darauf an, auf welcher Seite man sein Grundstück hat ;-) (ohne Privatbesitz oder privaten Nutzungsrechten spielt das keine Rolle) Und weil das alles so kompliziert und endlos ist, ziehe ich mich mal wieder zurück. Am liebsten wäre mir, ich könnte künftig bei Fragen einfach im Wiki nachschlagen, und fände dort eine zielführende Antwort :-) So wie Sepp schrieb: auch ich mag bei Frage nicht die History der ML durchforsten ;-) Mit herzlichem Gruss, Markus _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
