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
[email protected]
https://lists.openstreetmap.org/listinfo/talk-de
