Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Christian Müller]

> Gesendet: Sonntag, 22. April 2018 um 08:20 Uhr
> Von: mmd <mmd@gmail.com>
> An: talk-de@openstreetmap.org
> Betreff: Re: [Talk-de] Flächen/Wege // Trolling in changesets
>
> Ihr müsst einfach mal schauen, welche Datenmengen dahinter stecken.
> Momentan schleppen wir 4,4 Milliarden Nodes mit uns herum, davon 3,8
> Milliarden Nodes, die nur in irgendwelchen Ways vorkommen, [..]

Bis auf die Verweise und evtl. irgendwelche Metadaten (die aber für
attic + history Zwecke immer interessant bleiben) sehe ich nicht,
wie durch diese Verlagerung irgendetwas eingespart werden soll.

Du sprichst hier nur von einer lat/lon-Information, aber so einfach
ist das nicht.  Ein node-Objekt kann auch eine Historie mit mehreren
Revisionen haben, die u.U. für Mapper aber auch Anwender interessant
sein kann.

Außerdem erfüllt das node-Objekt in hohem Maß den Bedarf, es zu editieren,
es in den Knotenlisten der Wege neu einzuordnen, zu verschieben oder eben
von einem weiteren Weg (Kreuzung oder Straße über Straße (elevated high-
way)) referenziert zu werden.  Du schreibst, dass dieser Aspekt durch
ein Hybrid-Modell erhalten bliebe.  De facto bedeutet es für jeden Edit-
vorgang, dass Koordinaten ihren Status wechseln können (müssen), d.h.
von way-gebundener Koordinate zu eigenständigem Node wahlweise promo-
vier- oder eben herabstufbar sein müssen.


> Jedes Tool muss sich momentan einen riesigen Cache aufbauen, der zu der
> Node Id die entsprechenden Koordinaten zurück liefert, damit überhaupt
> klar ist, wie die Geometrie eines Ways aussieht.

Das ist für den vorwiegenden Anwendungsfall, einen relativ kleinen Daten-
ausschnitt zu laden, etwas zu verändern und es wieder hochzuladen häufig
nicht relevant, macht sich aber evtl. als Skaleneffekt bemerkbar, wenn
etwa der gesamte Planet verschnitten werden soll.

Warum versucht man nicht, die Vorteile, die sich durch diese Umverlagerung
ergeben können, durch eine Art Vorverarbeitung der Daten zu nutzen, die sich
dann nur damit beschäftigt, die Nodes je nach ihrer Verwendung in das Modell
des neuartigen way-Typs einzuordnen, bzw. ident zu belassen?

Es hört sich so an, als wenn so ein Hybrid auch mit den laufend verfügbaren
Changesets aktuell gehalten werden kann, was die Änderungsmenge nach einem
initialen Import minimiert.

Auf diese nebenläufige DB, die alle Änderungen im Abo bezieht, diese aber
wegen des geänderten Datenmodells erst nach Transformation/Vorverarbeitung
übernimmt, kann dann lesend zugegriffen werden (ob von Dumping- oder Edit-
Tools), womit sich parallel bequem Tools weiterentwickeln ließen, die dann
alternativ das hybride Modell verarbeiten.

Der (zu entwickelnde..) Daten-Trafo wäre Dreh-/Angel- und Einstiegspunkt.
Wenn im Trafo alle ways, die von einem Changeset geändert wurden, so um-
gerechnet werden können, dass kein Zugriff auf die Ziel-DB erfolgt, dann
darf die Wandlung Node->Koordinate eine Einbahnstraße sein. Das heißt
ein Mapping von Koordinate zu früherer Node-Id wäre dann für die Änder-
barkeit der ways in der Ziel-DB verzichtbar.

Dennoch, während zu Nodes promovierte Koordinaten durch diesen Trafo ihre
History dann einfach von A nach B kopieren könnten, wenn sie in B vorher
nur Koordinate waren, bedeutet das für einen späteren Live-Betrieb ohne A,
dass eine History (und Metadaten) für Nodes nicht mehr sinnvoll beibehalten
werden kann - es sei denn diese wird bei einer Abstufung mit in (alle!)
ways geschrieben.  Die zu behandelnden Edit-Fälle sind zahlreich, man
denke an das Verbinden und Trennen von gemeinsamen Wegknoten.

Um Erfahrungen zu sammeln, wäre das aber ein möglicher Pfad, der sich
gehen lässt, ohne den derzeitigen Live-Betrieb zu beeinträchtigen, imho.


Gruß

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[mmd]

Am 22.04.2018 um 07:30 schrieb "Christian Müller":

> 
>  Änderungen in diesen Kernbereichen laufen zum jetzigen Zeitpunkt stets gegen 
> die Macht der Gewohnheit und zahllose Abhängigkeiten "downstream" an, 
> weswegen Weiterentwicklungen in der API oder der DB-Objektlogik imho am 
> besten in neuen Projekten (Forks) aufgehoben sind.  Dieses Grundkonzept 
> node/way/relation ist in der jetzigen Form doch fast eine "heilige Kuh" und 
> der API-Versionsstand in der Kategorie "never change a running system" 
> (geworden), nicht?

Da bisher alle Forks grandios gescheitert sind, halte ich davon eher
wenig. Ich glaube, jeder teilt aber die Auffassung, dass eine Änderung
am Datenmodell generell eine Sachen von mehreren Jahren ist.

Als Vorteil sehe ich, dass eine Umstellung kein Big Bang sein muss. Es
wäre z.B. möglich, einen speziell aufbereiteten Planet zusätzlich
anzubieten und einzelne Tools schrittweise umzustellen (vor allem
Router/Renderer und ähnliches). Anpassung der Editoren wird ein extrem
spannendes Thema und irgendwann dann die Migration und Umstellung der
API - eben ein Projekt für mehrere Jahre.

-- 



___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[mmd]

Am 21.04.2018 um 23:20 schrieb Martin Koppenhoefer:
> 
>> On 21. Apr 2018, at 20:51, Christian Müller  wrote:
>>
>> Dennoch experimentierwürdig,

> finde ich unattraktiv, da ginge ja der topologische Zusammenhalt verloren, ob 
> es eine gemeinsame Grenze ist, oder ob die Grenze “zufällig” übereinstimmt, 
> dh. man müsste umständlich herausfinden, welche Grenzen jeweils 
> zusammengehören, für bestimmte Anwendungen (z.B. muss man beim Vereinfachen 
> von Grenzen nur jeweils eine Grenze vereinfachen für beide Nachbarn, würde 
> man jeweils die Grenze unabhängig vereinfachen würde sie danach nicht mehr 
> genau zusammenpassen). Das ist nicht nur irgendein Ausnahmefall sondern die 
> Grundlage für die Vektorkarten.
> 

Ihr müsst einfach mal schauen, welche Datenmengen dahinter stecken.
Momentan schleppen wir 4,4 Milliarden Nodes mit uns herum, davon 3,8
Milliarden Nodes, die nur in irgendwelchen Ways vorkommen, ohne
Verbindung zu anderen Ways und ohne eigene Tags. Die einzige
Nutzinformation ist hier die lat/lon-Information (Metadaten klammere ich
bewusst aus, da sie für Rendering oder Routing keine Rolle spielen).

Schieben wir diese Nodes als Koordinate in den Way und löschen die alten
Nodes, werden wir augenblicklich 85% der Nodes los. Das hat massive
Auswirkungen auf Hardwareanforderungen von Tools, die mit den Daten
arbeiten wollen.

Jedes Tool muss sich momentan einen riesigen Cache aufbauen, der zu der
Node Id die entsprechenden Koordinaten zurück liefert, damit überhaupt
klar ist, wie die Geometrie eines Ways aussieht.

Zum Thema topologischer Zusammenhalt: ich hatte eingangs ja schon
angesprochen, dass wir alternativ "Verbindungs"-knoten zu anderen Ways
weiterhin als Node behalten könnten, so dass überhaupt kein Unterschied
zum jetzigen topologischen Eigenschaften entsteht (wir nennen das
einfach mal "hybrides Modell"). Ebenso könnte sich in einem rein
"Koordinaten"-basierten Modell der Editor um solche Sachen kümmern
(Details offen).

Im schon mehrmals angesprochenen OSM Samstag Workshop wurde das
Topologiethema auch groß und breit diskutiert. Ich denke, da wird es in
der Zukunft wohl noch eine textbasierte Zusammenfassung geben, in der
die Vor/Nachteile der verschiedenen Optionen detailliert beschrieben werden.

-- 



___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Christian Müller]

> Gesendet: Samstag, 21. April 2018 um 23:20 Uhr
> Von: "Martin Koppenhoefer" <dieterdre...@gmail.com>
> An: "Openstreetmap allgemeines in Deutsch" <talk-de@openstreetmap.org>
> Betreff: Re: [Talk-de] Flächen/Wege // Trolling in changesets
>
> finde ich unattraktiv, da ginge ja der topologische Zusammenhalt verloren, ob 
> es eine gemeinsame Grenze ist, oder ob die Grenze “zufällig” übereinstimmt

So wie ich es verstanden habe, sollten erstmal nur die Koordinatenverweise in 
ways durch Koordinaten ersetzt werden, d.h. der mehrmalige Verweis auf ways 
z.B. in MP-Relationen wäre immer noch möglich.  Aber es stimmt schon: zwischen 
Punkten / Wegen wäre der topologische Zusammenhalt schwach und müsste für jede 
Aufgabe geometrisch durch "nearby"- oder "around"-Funktionen errechnet werden;  
ihn dann zwischen Wegen / Flächenrelationen in unveränderter Form zum status 
quo (bezugslogisch) vorzufinden, würde als Bruch im Design des Datenmodells 
erscheinen, ist aber nicht undenkbar.  Für OSM in seiner jetzigen Form würde 
das jede Menge Tools in die Überarbeitung nötigen.

Mit einer neuen API-Revision einen Flächentyp (d.h. den ways/nodes/relations 
gleichrangiges, separates DB-Objekt) einzuführen, ist dem gegenüber schon viel 
länger anhängig.  Da sich diesbzgl. viele Tools mit dem status quo über die 
Jahre arrangiert haben, besitzt das nun eine eher geringe Priorität und dürfte 
mit dem Unterfangen, die etablierten DB-Objekte und deren Bezugslogik 
umzustricken, in puncto Unbeliebtheit konkurrieren.  Änderungen in diesen 
Kernbereichen laufen zum jetzigen Zeitpunkt stets gegen die Macht der 
Gewohnheit und zahllose Abhängigkeiten "downstream" an, weswegen 
Weiterentwicklungen in der API oder der DB-Objektlogik imho am besten in neuen 
Projekten (Forks) aufgehoben sind.  Dieses Grundkonzept node/way/relation ist 
in der jetzigen Form doch fast eine "heilige Kuh" und der API-Versionsstand in 
der Kategorie "never change a running system" (geworden), nicht?


Gruß


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Martin Koppenhoefer]

sent from a phone

> On 21. Apr 2018, at 20:51, Christian Müller  wrote:
> 
> Dennoch experimentierwürdig,


finde ich unattraktiv, da ginge ja der topologische Zusammenhalt verloren, ob 
es eine gemeinsame Grenze ist, oder ob die Grenze “zufällig” übereinstimmt, dh. 
man müsste umständlich herausfinden, welche Grenzen jeweils zusammengehören, 
für bestimmte Anwendungen (z.B. muss man beim Vereinfachen von Grenzen nur 
jeweils eine Grenze vereinfachen für beide Nachbarn, würde man jeweils die 
Grenze unabhängig vereinfachen würde sie danach nicht mehr genau 
zusammenpassen). Das ist nicht nur irgendein Ausnahmefall sondern die Grundlage 
für die Vektorkarten.


Gruß,
Martin 
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Christian Müller]

> Gesendet: Samstag, 21. April 2018 um 10:40 Uhr
> Von: mmd 
> An: talk-de@openstreetmap.org
> Betreff: [Talk-de] Flächen/Wege // Trolling in changesets
>
> Soviel vorweg: sobald der "Node" nicht mehr als "Node", sondern nur noch
> als Koordinate im Way existiert, bringt Verkleben keinen wirklichen
> Vorteil mehr in Bezug auf den Node Count in der DB.

Das stimmt, aber das Entkoppeln der Wegkoordinaten von Punktkoordinaten
erzeugt dann an anderer Stelle overhead.  Objekte, die jetzt als node
in der DB getaggt werden (Ampeln, tmc-Punkte, etc. pp.) würden dann
nämlich auch nicht mehr diesselbe Koordinate teilen können..

Dennoch experimentierwürdig, natürlich - setzt aber auch das Umschreiben
einer ganzen Menge an Tools in der Toolchain voraus, weswegen ich mutmaße,
dass das so nicht in einer Folge-API für OSM erscheinen wird.  Als Startup
für neue Projekte aber durchaus denkbar.


Gruß

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Christian Müller]

> Gesendet: Samstag, 21. April 2018 um 10:07 Uhr
> Von: "Martin Koppenhoefer" <dieterdre...@gmail.com>
> An: "Openstreetmap allgemeines in Deutsch" <talk-de@openstreetmap.org>
> Betreff: Re: [Talk-de] Flächen/Wege // Trolling in changesets
>
> du nennst das „overhead“, als wären diese Informationen Redundanzen oder 
> zumindest nicht relevant, also etwas das man besser wegoptimieren würde, aber 
> das ist natürlich schon eine Wertung (dass man diesen Detailgrad eigentlich 
> nicht will oder braucht)

Nein, ich schrieb in der gleichen mail das dies anwendungsfallbezogen ist.  Das 
Wort wurde klar vergleichend verwendet, d.h. „overhead“ für den Fall, dass

a) entweder diese von dir angesprochene Wertung unlängst einen breiten Konsens 
hat
b) oder eben diese Anomalien gar nicht wahrheitsgetreu erfasst werden (können) 
(Thema Auflösungs-/Abbildungsfehler bzw. Pixelinterpretationen und 
Georeferenzierung der Luftbildquellen)

Der Vorredner hatte argumentiert, dass durch eine andere Wahl des Datenmodells 
die Anomalien ohne „overhead“ darstellbar wären, ob in der Annahme, es sei gar 
keine zusätzliche Information oder eben nicht, ging nicht eindeutig hervor.  
D.h. gewisserweise wurde anwendungsfallbezogen schon implizit angenommen, dass 
beide Methoden vergleichbar sind.

Diese Vergleichbarkeit scheint gar nicht gegeben zu sein, wenn bezüglich des 
Anwendungsfalls jedwede Wertungsfreiheit eingefordert oder vorausgesetzt wird.  
Man muss sich schon auf eine Schnittmenge von Anwendungsfällen sowohl der einen 
als auch der anderen Methode einlassen, wenn man überhaupt vergleichende 
Aussagen treffen will.

Gleichwohl wurde schon einmal festgestellt, dass jeder Mapper bestimmte 
Fragmente der Realität auswählt, die dann in OSM wiedergegeben werden.  Dieser 
niederschwellige Selektionsprozess erreicht evtl. dadurch Neutralität, dass es 
viele Beitragende gibt.  Ginge es darum, diese Willkür völlig aus dem Projekt 
zu streichen, entspräche OSM eher dem Automatisierungsansatz durch Robotik, den 
seit Jahren mit Google Earth und seiner 3d-Wiedergabe der vor Ort gemessenen 
Daten verfolgt.


Gruß

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Martin Koppenhoefer]

sent from a phone

> On 21. Apr 2018, at 04:04, Christian Müller  wrote:
> 
> Dieser dann eher häufig anzutreffende Fall stellt praktisch immer einen nicht 
> zu
> vernachlässigenden Overhead dar, der sich schlecht bis kaum durch eine 
> günstige
> Wahl der Datenrepräsentation optimieren lässt.  


du nennst das „overhead“, als wären diese Informationen Redundanzen oder 
zumindest nicht relevant, also etwas das man besser wegoptimieren würde, aber 
das ist natürlich schon eine Wertung (dass man diesen Detailgrad eigentlich 
nicht will oder braucht), und natürlich benötigen mehr Informationen im 
allgemeinen auch mehr Platz.

Es wurde schon erwähnt, aber zur Erinnerung, für mich steht neben der 
geringeren Komplexität die Wartbarkeit und Erweiterbarkeit im Vordergrund.

Gruß,
Martin 
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Christian Müller]

> Gesendet: Donnerstag, 19. April 2018 um 21:41 Uhr
> Von: mmd <mmd@gmail.com>
> An: talk-de@openstreetmap.org
> Betreff: Re: [Talk-de] Flächen/Wege // Trolling in changesets
>
> > Wenn verklebt wird, dann wird x
> > mal auf /die identen/ Knoten verwiesen, der Knoten (die Koordinate) aber
> > nur exakt einmal gespeichert.  Geometrisch parallel geführte Linien
> > erhöhen das Datenaufkommen (und den node-count in der DB) hingegen
> > drastisch.
> 
> Das gilt aber auch nur für das aktuelle Datenmodell bzw. der zugehörigen
> OSM API 0.6. Man kann sich ohne weiteres Alternativen vorstellen, in
> denen der vermeintliche Vorteil durch Verkleben praktisch keine Rolle
> mehr spielt, oder schlimmer noch, sich plötzlich ins Gegenteil verkehrt
> und sogar mehr Platz benötigt.

Das ist prinzipiell schon vorstellbar, allerdings wäre die Repräsentation
in der Datenstruktur dann auch ähnlich, mit ähnlichen /Ungenauigkeiten/,
da wird sich nichts plötzlich ins Gegenteil verkehren.

Außerdem wurde hier durch die Entkleber der Genauigkeitsaspekt in den Vorder-
grund gestellt, es geht beim /Entkleben/ also mitnichten um exakt parallele
Linien, sondern um solche, die durch minimale aber zahlreiche Anomalien ge-
genüber den idealisierenden Parallelen (bsp.weise zur Straßenkante) optisch
/auffallen/.

Dieser dann eher häufig anzutreffende Fall stellt praktisch immer einen nicht zu
vernachlässigenden Overhead dar, der sich schlecht bis kaum durch eine günstige
Wahl der Datenrepräsentation optimieren lässt.  Diese Anomalien können eben 
nicht
durch Extrusion/Parallelverschiebung erzeugt werden.

Gerade das ist ja Florian's Argumentation gewesen, dem es um diese hohe 
Exaktheit
ging, weil sie von Luftbildern ableitbar und anhand dieser einfacher 
verifizierbar
ist, als wenn eine höhere Abstraktionsstufe der Datenrepräsentation gewählt 
wird,
aus welcher mittels Algorithmen diese Anomalien eben so nicht reproduzierbar 
sind.

Reproduziert wird bei verklebten Daten eine Approximation/Näherung, die diese
Anomalien/Abweichungen wegabstrahiert bzw. glättet und ob dieser Fehler vernach-
lässigbar ist, hängt vom Anwendungsfall ab.  Für die Entkleber ist also "ground
truth" ein gutes Argument, allerdings können sie das dann eben auch nur nutzen,
wenn sie alle Straßen als Fläche erfassen, und die Mittellinie als eigentliche
Repräsentation (bzw. "Allround-Repräsentation") des Straßenobjekts aufgeben. Die
hat nämlich gemessen am aktuellen Diskussionsgegenstand mit "ground truth" eher
wenig zu tun und stellt stattdessen eine sehr hohe Abstraktionsform bzw. eine
starke Idealisierung eines realen Objekts vor Ort dar.

Wenn man beachtet, dass die Ausrichtung bzw. Georeferenzierung der Luftbilder 
einen
für OSM-Mapper in der Größenordnung oft nicht oder schlecht ersichtlichen 
Lagefehler
besitzen, dann stellt sich nicht nur die Frage nach der Sinnhaftigkeit, 'zig 
nodes
für die Erfassung dieser Anomalien zu ver"sch"wenden, sondern auch, ob sie 
tatsäch-
lich lagerichtig erfasst werden (können).

Das wurde so oder so ähnlich aber alles schon gesagt.


Gruß

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[mmd]

Am 08.04.2018 um 19:37 schrieb "Christian Müller":
>>> Das Verkleben ist im Hinblick darauf, die Größe der DB klein zu halten,
>>> heute scheinbar nicht mehr so wichtig.
>> Das hat die Datenbank nie kleiner gemacht. Wenn du verklebst haben ALLE
>> Wege die zusätzlichen Knoten. Tausche Anzahl Knoten gegen Anzahl Knoten
>> je Weg. Vorher hatte ich 10 Knoten in 3 Wegen. Jetzt habe ich 30 Knoten,
>> 10 je Weg.
> Oh, das ist eine Milchmädchenrechnung:  Wenn verklebt wird, dann wird x
> mal auf /die identen/ Knoten verwiesen, der Knoten (die Koordinate) aber
> nur exakt einmal gespeichert.  Geometrisch parallel geführte Linien
> erhöhen das Datenaufkommen (und den node-count in der DB) hingegen
> drastisch.

Das gilt aber auch nur für das aktuelle Datenmodell bzw. der zugehörigen
OSM API 0.6. Man kann sich ohne weiteres Alternativen vorstellen, in
denen der vermeintliche Vorteil durch Verkleben praktisch keine Rolle
mehr spielt, oder schlimmer noch, sich plötzlich ins Gegenteil verkehrt
und sogar mehr Platz benötigt.

Ich will das jetzt nicht weiter ausführen, der Thread ist eh schon viel
zu lang. Interessierte können sich gerne dazu die Aufzeichnung
"Evolution des OpenStreetMap-Datenmodells" vom OSM Samstag ansehen.

-- 












___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Christian Müller]

> Gesendet: Donnerstag, 19. April 2018 um 14:49 Uhr
> Von: "Martin Koppenhoefer" <dieterdre...@gmail.com>
> An: "Openstreetmap allgemeines in Deutsch" <talk-de@openstreetmap.org>
> Betreff: Re: [Talk-de] Flächen/Wege // Trolling in changesets
>
> nicht von anderen Karten kopieren, und any tags you like? Oder welche Regeln 
> meinst Du? Nicht für den Renderer taggen und groundtruth?


Nachtragend zu letzter mail noch eine weitere Quelle:
https://web.archive.org/web/20180201020126/https://www.tinohempel.de/info/info/fortbildungen/OSM.pptx

Ad hoc ließ sich über die Google Büchersuche
aber z.B. keine gedruckte Publikation finden,
in welcher diese so verewigt wären.  In
https://books.google.de/books?id=UpLjCQAAQBAJ

z.B. findet die Google Büchersuche nur die
erste der beiden Regeln, in klausulierter bzw.
erklärender Form.


Gruß

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Christian Müller]

> Gesendet: Donnerstag, 19. April 2018 um 14:49 Uhr
> Von: "Martin Koppenhoefer" <dieterdre...@gmail.com>
> An: "Openstreetmap allgemeines in Deutsch" <talk-de@openstreetmap.org>
> Betreff: Re: [Talk-de] Flächen/Wege // Trolling in changesets
>
> nicht von anderen Karten kopieren, und any tags you like? Oder welche Regeln 
> meinst Du? Nicht für den Renderer taggen und groundtruth?


https://josm.openstreetmap.de/wiki/De%3AStartupPage
(siehe unten)

https://forum.openstreetmap.org/viewtopic.php?pid=664061#p664061
(siehe mittig)

https://wiki.openstreetmap.org/w/index.php?title=File:ThailandOSSfestival2010.pdf=15

etc. pp.


Interessanterweise nicht direkt im Wiki zu finden,
z.B. auf der FAQ-Seite - oder ich habe nicht richtig
gesucht und gefunden.


Gruß

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Martin Koppenhoefer]

sent from a phone

> On 19. Apr 2018, at 03:42, Christian Müller  wrote:
> 
> Außerdem sollte man sich an
> die beiden goldenen Regeln von OSM erinnern.


nicht von anderen Karten kopieren, und any tags you like? Oder welche Regeln 
meinst Du? Nicht für den Renderer taggen und groundtruth?

Gruß,
Martin 
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Christian Müller]

> Gesendet: Mittwoch, 18. April 2018 um 23:26 Uhr
> Von: "Michael Reichert" <osm...@michreichert.de>
> An: "Openstreetmap allgemeines in Deutsch" <talk-de@openstreetmap.org>
> Betreff: Re: [Talk-de] Flächen/Wege // Trolling in changesets
>
> An deiner Stelle würde ich die DWG bitten, ihn zu verwarnen, weil sein
> Verhalten demotivierend und störend ist. Weitere Maßnahmen gegen ihn
> können bei Bedarf später ergriffen werden.

Erinnert sich noch jemand daran, dass OSM selbst disruptiv und störend
war, solange es sich verbreitert hat?  Eine klare Motivation in der An-
fangsphase war, das Geschäftsmodell von Druckkartendiensten, wie auch
das von Google Maps in Frage zu stellen, bzw. unter Druck zu setzen.

Mit Verwarnsüchten und "Maßnahmen" tritt man die Bemühungen der Frei-
willigen, eine "freie Weltkarte" zu gestalten, zu erhalten und fördert
klar den Kommerz.  Andere Meinungen und Methoden haben das Projekt
schon immer bereichert, weil man dadurch eine wesentlich bessere
Sichtweise auf die Alternativen gewinnen kann, die ein geg. Problem
lösen.  Demotivierend ist, wenn es nicht gelingt, dieses Ökosystem
in seiner Vielfalt zu erhalten, imho.  Außerdem sollte man sich an
die beiden goldenen Regeln von OSM erinnern.


Gruß

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Christian Müller]

> Gesendet: Mittwoch, 18. April 2018 um 23:41 Uhr
> Von: "Hartmut Holzgraefe" <hartmut.holzgra...@gmail.com>
> An: talk-de@openstreetmap.org
> Betreff: Re: [Talk-de] Flächen/Wege // Trolling in changesets
>
> "There is not clear consensus yet ..."
> 
> "That being said, when the way is a highway, it usually is most accurate 
> to include a gap, so that the area ends by the side of the road and does 
> not share nodes with the road's way. This is because highway ways 
> usually are traced along the centerline of the road, and it is unlikely 
> that the area being tagged actually extends to the center of the road."
> 
> Das liest sich beides irgendwie nicht so wirklich wie dass was ich mir
> unter:
> 
> "gemäß Wiki anerkannte Methode"

Es liest sich so, als dass sowohl das eine als auch das andere vorzufinden
ist und weder das eine noch das andere falsch ist.  Die Wiki-Seite gibt
wieder, was auch in der Mailing-Liste anhand dieser Diskussion zu sehen
ist:  Es gibt keine klare Einigung unter den Beitragenden.

Nichts desto trotz tendiert die Wiki-Seite dazu eine Empfehlung für das
Entkleben auszusprechen (ebenso ohne klaren Konsens, wird wohl pers.
Meinung des Wiki-Schreibers sein).

Außerdem stellen diese Zitate klar, dass nicht /die/ "centerline" ge-
mappt wird, sondern der highway (Weg/Straße) unter /Zuhilfename/ einer
solchen.  Zudem "usually", d.h. üblicherweise/grob/ungefähr - man kann
sich nicht in allen Gebieten darauf verlassen, dass der 1-dimensionale
Vertreter (Linienzug) in den Daten für das 3-dimensionale Objekt vor Ort
stets die Position der Weg/Straßen-Mittellinie wiedergibt.  Stammen die
Daten aus einem GPS-Trace ist das sogar unwahrscheinlich, da der GPS-
Empfänger seltenst auf der Mittellinie entlang geführt werden wird.


Gruß

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Hartmut Holzgraefe]

On 18.04.2018 20:07, Florian Lohoff wrote:


==
Das progressive Teilen von Nodes durch Flächen und Wegen ist eine gemäß 
Wiki anerkannte Mappingmethode. Der Weg repräsentiert dabei nicht 
ausschließlich die Fa
hrbahmitte sondern insbesondere in Verbindung mit dem width-Attribut, 
hilfsweise auch mit Standardwerten, die gesamte Fahrbahn. Selbstverständlich 
geht der Pa
rkplatz nicht bis zur Fahrbahnmitte. Das wird mit dieser Mappingmethode 
auch nicht behauptet. Wenn das Dein Renderer oder Dein Editor anders darstellt 
ist das
 kein Fehler. 
https://wiki.openstreetmap.org/wiki/Editing_Standards_and_Conventions#Areas_and_Ways_Sharing_Nodes
==



"lustig" dass die verlinkte Wikiseite in dem Abschnitt auch sagt:

"There is not clear consensus yet ..."

"That being said, when the way is a highway, it usually is most accurate 
to include a gap, so that the area ends by the side of the road and does 
not share nodes with the road's way. This is because highway ways 
usually are traced along the centerline of the road, and it is unlikely 
that the area being tagged actually extends to the center of the road."


Das liest sich beides irgendwie nicht so wirklich wie dass was ich mir
unter:

"gemäß Wiki anerkannte Methode"

vorstellen würde?


--
hartmut

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Michael Reichert]

Hallo Flo,

Am 18.04.2018 um 20:07 schrieb Florian Lohoff:
> Das trolling von OF0 geht wieder los - soifz ... 
> 
>   Hi flohoff,
> 
>   OF0 has left a comment on a map changeset you are watching created by 
> HolgerJeromin at 2018-04-18 18:03:52 UTC
>   with comment 'Details per Luftbild'
> 
>   ==
>   Das progressive Teilen von Nodes durch Flächen und Wegen ist eine gemäß 
> Wiki anerkannte Mappingmethode. Der Weg repräsentiert dabei nicht 
> ausschließlich die Fa
>   hrbahmitte sondern insbesondere in Verbindung mit dem width-Attribut, 
> hilfsweise auch mit Standardwerten, die gesamte Fahrbahn. Selbstverständlich 
> geht der Pa
>   rkplatz nicht bis zur Fahrbahnmitte. Das wird mit dieser Mappingmethode 
> auch nicht behauptet. Wenn das Dein Renderer oder Dein Editor anders 
> darstellt ist das
>kein Fehler. 
> https://wiki.openstreetmap.org/wiki/Editing_Standards_and_Conventions#Areas_and_Ways_Sharing_Nodes
>   ==
> 
>   More details about the changeset can be found at 
> http://www.openstreetmap.org/changeset/58204223.
> 

An deiner Stelle würde ich die DWG bitten, ihn zu verwarnen, weil sein
Verhalten demotivierend und störend ist. Weitere Maßnahmen gegen ihn
können bei Bedarf später ergriffen werden.

Viele Grüße

Michael

-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Florian Lohoff]

On Mon, Apr 02, 2018 at 12:03:50AM +0200, Florian Lohoff wrote:
> 
> Hi,
> 
> ich habe vor ein paar Wochen angefangen in meinem Dunstkreis
> (Ostwestalen-Lippe) Systematisch alle "verklebten Flächen und Wege"
> aufzulösen. Ich finde das selber zum bearbeiten extrem nervig und vor
> allem sind die Daten zumeist extrem ungenau - Teilweise noch aus Bing
> Zeiten, riesige Landuses die willkürlich mit Straßen verbunden sind.

Das trolling von OF0 geht wieder los - soifz ... 

Hi flohoff,

OF0 has left a comment on a map changeset you are watching created by 
HolgerJeromin at 2018-04-18 18:03:52 UTC
with comment 'Details per Luftbild'

==
Das progressive Teilen von Nodes durch Flächen und Wegen ist eine gemäß 
Wiki anerkannte Mappingmethode. Der Weg repräsentiert dabei nicht 
ausschließlich die Fa
hrbahmitte sondern insbesondere in Verbindung mit dem width-Attribut, 
hilfsweise auch mit Standardwerten, die gesamte Fahrbahn. Selbstverständlich 
geht der Pa
rkplatz nicht bis zur Fahrbahnmitte. Das wird mit dieser Mappingmethode 
auch nicht behauptet. Wenn das Dein Renderer oder Dein Editor anders darstellt 
ist das
 kein Fehler. 
https://wiki.openstreetmap.org/wiki/Editing_Standards_and_Conventions#Areas_and_Ways_Sharing_Nodes
==

More details about the changeset can be found at 
http://www.openstreetmap.org/changeset/58204223.

Flo
-- 
Florian Lohoff f...@zz.de
 UTF-8 Test: The  ran after a , but the  ran away


signature.asc
Description: PGP signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Martin Koppenhoefer]

sent from a phone

> On 9. Apr 2018, at 23:26, Michael Reichert  wrote:
> 
> Ich möchte anmerken, dass ein nicht ganz kleiner Teil (könnte auch die
> Mehrheit sein), die Verwendung von Multipolygonen ablehnt oder gar
> ächtet, wenn sie mehrere Mitglieder mit der Rolle "outer" enthalten, die
> gemeinsam genau einen Ring bilden und es keine Mitglieder der Rolle
> "inner" gibt.


ich vermute, ein Teil dieser Ablehnung beruht auch darauf, dass Multipolygone 
lange Zeit als Relationen für Löcher verkauft wurden, und wenn es dann kein 
Loch gibt, wird die Relation als unnötig empfunden, denn es geht „gut“ anders.

Die Alternative sind sich an den Rändern überlappende Wege, deren Herstellung, 
selbst mit zig und hunderten Nodes, durch Josm supereinfach ist (einfach ein 
Gewicht auf die f-Taste stellen und aufs Klo gehen). Das Bearbeiten der daraus 
resultierenden Geflechte hingegen ist komplizierter und arbeitsaufwendiger als 
das Bearbeiten einer Relation (z.B. weil man die richtigen Wege selektieren und 
splitten muss, und nach dem Splitten die richtigen Teile der überlappenden ways 
selektieren), und je mehr nodes der mehrfache Weg hat, um so mehr Redundanz 
wird damit geschaffen.

Ja, eine Relation erhöht die Komplexität, aber man muss sie trotzdem nicht um 
jeden Preis vermeiden wo sie sinnvoll ist (und damit meine ich nicht nur für 
Löcher). Selbst MP relationen mit nur 1 member (outer) machen oft Sinn, sondern 
man die Sachen eindeutig darzustellen bestrebt ist.

Gruß,
Martin 
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Michael Reichert]

Hallo,

Am 04.04.2018 um 15:43 schrieb "Christian Müller":
> In OSM sind derzeit drei wesentliche Methoden beobachtbar, die ver-
> suchen diesen Sachverhalt abzubilden:
> 
> 1) ein Abschnitt (way) der sowohl Fläche A und B begrenzt, nimmt in der
> Rolle 'outer' als Mitglied in den MP-Relationen für je A und B teil.
> 
> 2) Für A und B werden zwei Wege (ways) benutzt (overlapping ways),
> die sich eine Knotenfolge teilen (diese Folge wird in der Daten-
> struktur für diese ways wiederholt)
> 
> 3) Zwei ways mit voneinander unabhängigen Knoten bzw. -folgen werden
> als Grenzen gezeichnet; die gemeinsame Flächengrenze wird durch zwei
> Linien approximiert - mal ist Luft dazwischen, mal schneiden sich
> Wegsegmente und die Flächen überlappen sich unabsichtlich etwas.
> 
> 
> M.M.n. ist 1) die zu bevorzugende Variante, um Sachverhalte vor Ort
> und am Boden abzubilden.  Es folgt den "best practices" im OSM Wiki.
> Dort wird empfohlen, für jedes zu erfassende Objekt der Realität,
> genau ein entsprechendes Objekt in der Datenbank anzulegen:
Ich möchte anmerken, dass ein nicht ganz kleiner Teil (könnte auch die
Mehrheit sein), die Verwendung von Multipolygonen ablehnt oder gar
ächtet, wenn sie mehrere Mitglieder mit der Rolle "outer" enthalten, die
gemeinsam genau einen Ring bilden und es keine Mitglieder der Rolle
"inner" gibt. Man nennt das dann auch Multipolygonitis. Es sind schon
Mapper dafür gesperrt worden, unnötig viele Multipolygon-Relationen
anzulegen, obwohl andere Communitymitglieder sie gebeten haben,
Multipolygonrelationen weniger intensiv einzusetzen.

Ich wollte das nur mal gesagt haben, ohne jemandem konkrekt zu drohen.

Viele Grüße

Michael

-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Garry]

Am 08.04.2018 um 23:43 schrieb "Christian Müller":

Gesendet: Sonntag, 08. April 2018 um 22:21 Uhr
Von: "Martin Koppenhoefer" <dieterdre...@gmail.com>
An: "Openstreetmap allgemeines in Deutsch" <talk-de@openstreetmap.org>
Betreff: Re: [Talk-de] Flächen/Wege // Trolling in changesets

im Prinzip unterschreibe ich das, nur dass ich die Befürchtung von Florian 
teile, dass es im realen OSM-Alltag leicht in der Folge zu Topologiefehlern 
kommt, weil viele Mapper die Struktur der Daten nicht richtig bzw. vollständig 
erkennen.

Auch wenn man sowas z.B. mit JOSM extrem schnell zeichnen kann (einfach schnell 
f drücken), ist das Resultat eigentlich nicht so einfach, obwohl es aufgeräumt 
aussieht, und das wegen der mehrfachen überlappenden Linien.

Die Frage die sich stellt ist doch, ob das mehr an Linien dazu führt, dass 
Mapper dann die Struktur der Daten eher/öfter richtig erfassen?
Es bietet sich die Möglichkeit z.b. landuse und highway gegenseitig 
auszublenden. Wenn ich hochgenaue Daten nur des einen Typs habe kann ich 
diese Daten einpflegen ohne den anderen Typ, über den ich keine 
Informationen habe zu beeinflußen.


Beispiel:
Markante Form einer Ackergrenze entlang eines Straßen- oder Bahndammes 
in unebenem Gelände. Der Verkehrsweg hat in der Regel einen "stetigen" 
Verlauf während die Ackergrenze "Sprungstellen"/wechselnde Abstände zum 
Verkehrsweg hat. Da stecken dann Informationen drin, die zur 
Wiedererkennung aus der Luftbildperspektive hilfreich sind.


Gerald

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Christian Müller]

> Gesendet: Sonntag, 08. April 2018 um 22:40 Uhr
> Von: "Martin Koppenhoefer" <dieterdre...@gmail.com>
> An: "Openstreetmap allgemeines in Deutsch" <talk-de@openstreetmap.org>
> Betreff: Re: [Talk-de] Flächen/Wege // Trolling in changesets
>
> das stimmt so nicht ganz, weil wenn ich eine Straße mit dem Acker auf der 
> linken Seite verbinde, und mit dem auf der rechten Seite, dann verbinde ich 
> auch die beiden Äcker miteinander, obwohl die gar nicht verbunden sind in der 
> Realität. D.H. zumindest die Komplexität fürs Auswerten ist nicht zu 
> unterschätzen, man könnte es aber auch als Fehler werten, je nach Definition.

+1, das stimmt.  Allerdings ist die Auswertung im anderen Modell auch nicht für 
alle Fragen einfach.  Wenn man den hybriden Aspekt mit der Zeit rauswachsen 
lassen will, muss man sich um eine Definition kümmern, welche z.B. die 
Verwendung von highway=* auf Flächengrenzen ausschließt.

Man schließt damit dann aber auch aus, Aspekte der Realität, wo das vielleicht 
wirklich doch genau so der Fall ist, gut zu modellieren.  Ich erinnere an 
Fußgängerüberwege, die keine sind, aber zu Routingzwecken eingemalt werden - 
das sind Geisterlinien, die keinen verifizierbaren Aspekt der Realität 
darstellen.  Die Gefahr besteht, dass sich so etwas Ähnliches dann wiederholt, 
wenn die Verwendung von highway=* ways programmatisch eingeschränkt wird.


Gruß

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Martin Koppenhoefer]

sent from a phone

> On 8. Apr 2018, at 23:43, Christian Müller  wrote:
> 
> Die Frage die sich stellt ist doch, ob das mehr an Linien dazu führt, dass 
> Mapper dann die Struktur der Daten eher/öfter richtig erfassen?


wenn diese Linien sich in der Realität jeweils gut erkennen lassen, dann bin 
ich da guter Hoffnung. Je abstrakter es ist, um so mehr Leute steigen aus.


Gruß,
Martin 



___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Christian Müller]

> Gesendet: Sonntag, 08. April 2018 um 22:21 Uhr
> Von: "Martin Koppenhoefer" <dieterdre...@gmail.com>
> An: "Openstreetmap allgemeines in Deutsch" <talk-de@openstreetmap.org>
> Betreff: Re: [Talk-de] Flächen/Wege // Trolling in changesets
>
> im Prinzip unterschreibe ich das, nur dass ich die Befürchtung von Florian 
> teile, dass es im realen OSM-Alltag leicht in der Folge zu Topologiefehlern 
> kommt, weil viele Mapper die Struktur der Daten nicht richtig bzw. 
> vollständig erkennen.
> 
> Auch wenn man sowas z.B. mit JOSM extrem schnell zeichnen kann (einfach 
> schnell f drücken), ist das Resultat eigentlich nicht so einfach, obwohl es 
> aufgeräumt aussieht, und das wegen der mehrfachen überlappenden Linien.

Die Frage die sich stellt ist doch, ob das mehr an Linien dazu führt, dass 
Mapper dann die Struktur der Daten eher/öfter richtig erfassen?

Ich habe mittlerweile auch schon viele Flächenumrisse von Straßenkörpern 
gezeichnet, durfte mir aber mit der letzten Mail (an Florian) in Erinnerung 
rufen, dass die Verfügbarkeit der expliziten Straßengrenzen nicht in allen 
Fällen dazu führt, dass Flächen nicht mit der Mittellinie verbunden werden.  
Wenn es um gleichrangige Flächen geht, mag das so sein, aber eine 
Stadtbezirksfläche und damit -grenze wird man evtl. weiter mit der Mitte der 
Straße vernähen wollen, als mit der -kante.


Gruß

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Martin Koppenhoefer]

sent from a phone

> On 8. Apr 2018, at 23:32, Christian Müller  wrote:
> 
>  Und die
> verschiedenen Anwendungen, die Standardwerte für irgendwelche
> Breiten ungefähr annehmen gehören genauso zu OSM wie das doku-
> mentierte width-Tag.  OSM besteht nicht nur aus der DB!  Es
> ist ein verteiltes Ökosystem.


ich mir fällt ehrlich gesagt spontan keine einzige Anwendung im OSM Umfeld ein, 
die eine Straßenbreite annimmt (von abstrakten Breiten wie 2-spurig mal 
abgesehen). Hast Du mal ein Beispiel was Du damit meinst?

Gruß,
Martin 
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Christian Müller]

> Gesendet: Sonntag, 08. April 2018 um 21:15 Uhr
> Von: "Florian Lohoff" <f...@zz.de>
> An: "Christian Müller" <cmu...@gmx.de>
> Cc: talk-de@openstreetmap.org
> Betreff: Re: [Talk-de] Flächen/Wege // Trolling in changesets
>
> falscher wäre. Das einzige was eine valide Breite wäre wäre ein "width"
> tag das aber vernachlässigbare verbreitung findet und auch von
> keinem Datenkonsumenten ausgewertet wird.

"Don't bend the data", ja?  Just be patient.  Wie willst du auf der
Grundlage fehlender Daten argumentieren, dass die Linie nur etwas
/repräsentiert/, dass in der Realität gar nicht da ist??

Das ist absurd!  Und das ist so auch nicht dokumentiert.  Und die
verschiedenen Anwendungen, die Standardwerte für irgendwelche
Breiten ungefähr annehmen gehören genauso zu OSM wie das doku-
mentierte width-Tag.  OSM besteht nicht nur aus der DB!  Es
ist ein verteiltes Ökosystem.


> > Es ist eine Frage der Datenverwendung, ob der Linienzug und die assozi-
> > ierten Attribute zur Rekonstruktion der räumlichen Ausdehnung in 1, 2
> > oder 3 Dimensionen verwendet werden.
> 
> Nein - Man kann keine Tangente an einen Punkt konstruieren.

Niemand sprach von Punkten.  1 Dimension: Länge, 2 Dimensionen: Länge
plus Breite, 3 Dimensionen: Länge + Breite + Höhe

Verläuft der Straßenkörper annähernd gerade, reichen zwei Werte und eine
Linie um nach Belieben den ursprünglichen Körper rekonstruieren zu können,
je nachdem wieviele seiner Dimensionen für den Anwendungsfall benötigt
werden.


> Das ist jetzt nen bischen billig die Nummer. Es ist eben kein beliebiger
> extrusion algorithmus.

Doch ist es.  Simple is beautiful.  Komplizierter ist es für das 3D-
Mapping eigentlich auch nicht und das funktioniert schließlich bestens,
ohne die Lohoff'schen Einwände und Sorgen.  Es ist genauso nicht perfekt,
enthält abstraktionsbedingt Fehler, aber niemand kann und war darauf aus,
jeden Punkt der Realität in OSMs Datenbank abzubilden.


> Nein - Es prägt was mit den Daten möglich ist Mathematisch und was eben
> nicht - Und wenn dann Behauptungen in den Raum gestellt werden so wie
> von dir das das  ja "kein problem" sei oder "mathematisch nicht
> aufwendig" oder "problemlos" oder "allgemeine praxis" dann weiss ich
> daran schon das derjenige es nie selber probiert hat.

Du liest wahrscheinlich immer nur den Anfang meiner mails.  Es IST kein
Problem eine Fläche mit relativ konstanter Breite, die als Linie idealisiert
wurde mit der zugehörigen Breiteninformation unter Verwendung der Extru-
sionsmethode geometrisch zu reproduzieren.


> Ich bin echt müde dir jetzt aus einem OSM XML das auszurechnen das es
> günstiger ist weil dann kommt die nächste Schutzbehauptung und die
> nächste - Glauben ist halt das Gegenteil von Wissen. Vergleich dazu
> Gunkl und die Mondlandung.

Lächerlich, das ist doch selbst eine Schutzbehauptung!  Rechne es
doch einfach nach und trete damit an.


> talk-de ist vielleicht nicht der richtige Platz die Philosophischen
> Aspekte zu diskutieren die dir da jetzt so vorschweben.

?


> Es sind keine Momentaufnahmen sondern bezogen auf die Technischen Mittel
> des Eintragen möglichst genau zu erfassende Verifizierbare Daten.

Ja, die Erde ist eine Scheibe.  Amen.  Bei uns gab es mal einen Kirschbaum,
den konnte man recht lange verifizieren.  Heute steht da ein Poller.  An
anderer Stelle war mal eine Gärtnerei, da ist jetzt ne Tankstelle.  Alles
Momentaufnahmen, verifizierbar für kürzeste Zeit.  Die ganze Karte ist
eine Momentaufnahme und in bestimmten Details stets inaktuell.

Vielen Dank für deine Links, die ich alle sehr gut kenne.  Wie du
sehen kannst, können die kaum eindeutig sein, hätten wir doch hier
sonst keine Meinungsverschiedenheiten und würden im Gleichklang
tönen.

Momentaufnahmen sind verifizierbare Daten, für den Moment.


> Völlig irrelevant - Es geht nicht darum eine Fläche zu validieren 
> sondern es źu unterlassen absichtlich und aus purer Bequemlichkeit oder
> für den Renderer einen Fehler hinzuzufügen. 

Du verstehst es immer noch nicht.  Das was du als Fehler ansiehst,
ist in einem anderen Kontext kein Fehler.  Selbst die Ackergrenze
verschiebt sich von Jahr zu Jahr.  Willst du den Bauern jetzt auch
noch anhauen, dass der gerade fahren soll, damit du bei deiner Ein-
Meterdiskussion recht behältst?

Ohne Validierungsregel kann hier keiner behaupten, dass etwas
falsch ist, weil der (ich wiederhole mich..) /Bezugsrahmen/
nicht geklärt ist und eben auch nicht überprüft wird.

Du hast halt deinen Bezugsrahmen in dem das ein Fehler ist,
der nächste hat einen anderen, wo deine Linie einen Fehler
darstellt.  Es ist müßig darüber zu diskutieren.  Wenn du
hier so deinen Willen durchdrücken willst, dann darfst du
die Leute nicht anbetteln, dass so und so einzuhalten, son-
dern musst einen Regelsatz aufstellen,

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Martin Koppenhoefer]

sent from a phone

> On 8. Apr 2018, at 19:37, Christian Müller  wrote:
> 
> Nein, verkleben ist einfach nur die topologische Verbindung von zwei
> Objekten, die nebeneinander lieben.  Sie haben i.d.R. vor Ort eine
> gemeinsame Flächengrenze (sind also auch vor Ort verklebt).  Dass
> das in den Daten unrichtig wirkt(e) liegt an der Wahl der Repräsen-
> tation der geographischen Fakten


das stimmt so nicht ganz, weil wenn ich eine Straße mit dem Acker auf der 
linken Seite verbinde, und mit dem auf der rechten Seite, dann verbinde ich 
auch die beiden Äcker miteinander, obwohl die gar nicht verbunden sind in der 
Realität. D.H. zumindest die Komplexität fürs Auswerten ist nicht zu 
unterschätzen, man könnte es aber auch als Fehler werten, je nach Definition.

Gruß,
Martin 
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Martin Koppenhoefer]

sent from a phone

> On 8. Apr 2018, at 19:37, Christian Müller  wrote:
> 
> Irgendwer hatte mal gemeint, dass man Flächen auch nur durch Punkte
> und Aussagen darüber, zu welchen Flächen diese Punkte gehören, modellieren
> kann  (also nicht nur flächengrenzbezogene Punkte, sondern auch innen
> liegende). Man rastert die Fläche also unregelmäßig mit fortschreitend
> mehr Samples, die Genauigkeit steigt mit der Anzahl der erfassten Punkte.
> 
> Das wird in OSM gar nicht verwendet, aber es ist denkbar, dass auch
> das mit der Zeit zu Ergebnissen führt, die mit den derzeit in OSM
> verwendeten Methoden konkurrieren können.


damals ging es um unscharfe Grenzen von geografischen Gebieten,  die man 
iterativ so definieren könnte indem man über einzelne, bereits vorhandene 
Objekte sagt was innerhalb und ggf. außerhalb liegt. Für diesen Anwendungsfall 
klingt das immer noch nach einem interessanten Ansatz.

Gruß,
Martin 
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Martin Koppenhoefer]

sent from a phone

> On 8. Apr 2018, at 19:37, Christian Müller  wrote:
> 
> Ich behaupte nicht, dass sich damit /in jedem Fall/ Flächenumrisse von Wegen 
> er-
> setzen oder perfekt rekonstruieren lassen, aber es ist oft gut genug und nie 
> topo-
> logisch falsch.


im Prinzip unterschreibe ich das, nur dass ich die Befürchtung von Florian 
teile, dass es im realen OSM-Alltag leicht in der Folge zu Topologiefehlern 
kommt, weil viele Mapper die Struktur der Daten nicht richtig bzw. vollständig 
erkennen. 

Auch wenn man sowas z.B. mit JOSM extrem schnell zeichnen kann (einfach schnell 
f drücken), ist das Resultat eigentlich nicht so einfach, obwohl es aufgeräumt 
aussieht, und das wegen der mehrfachen überlappenden Linien.

Gruß,
Martin 
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Florian Lohoff]

Hola

On Sun, Apr 08, 2018 at 07:37:59PM +0200, "Christian Müller" wrote:
> Genau so, wie ein Routing-Graph /nur/ ein weiteres Beispiel ist, diese
> Datensammlung zu benutzen.  Weder das eine noch das andere wird idealer-
> weise bevorzugt.
> 
> Eigentlich ist es großer Mist, dass nur das credo
> "Wir mappen nicht für Renderer."
> so weit verbreitet ist, denn in gleicher Weise müsste sich
> "Wir mappen nicht für Routing-Engines."
> dazugesellen.

Das liegt daran das das einer der ganz ursprünglichen Maximen
von OSM ist und war:

https://wiki.openstreetmap.org/wiki/Good_practice#Don.27t_map_for_the_renderer

> > Wenn wir die Straße mit einer korrekten Breite erfassen
> > dann gibt es für den Straßenabschnitt 2 Objekte. Die Mittellinie als
> > geometrische Mitte der Straße mit allen Attributen wie
> > Geschwindigkeitsbeschränkung etc und eine Objekt mit der Ausdehnung -
> > Eine Highway Area.
> 
> Ja, das ist /jetzt/ so, /und/ es ist immer noch experimentell.  Es hat
> sich noch nicht überall durchgesetzt, dass die Erfassung der highway
> area sinnvoll ist; da gibt es noch viele Zweifelnde.

Auch das ist eine maxime der OSM 

https://wiki.openstreetmap.org/wiki/Good_practice#Don.27t_map_for_the_renderer

"They are continually improving, don't bend the data to make it
look prettier, just be patient. "

Und verkleben ist "bend the data" - Ganz einfach.

> Historisch gesehen wurde eine Straße eigentlich nur dort mit Flächen-
> umriss (also highway area) benutzt, wo eine konstante Breite des zu
> erfassenden Objekts fehlte.

Diese Konstante breite gibt es nicht in OSM - Die fügt Mapnik,
Osmarender, OsmAND, Mapbox  hinzu - Und zwar jeder so wie er will,
meint und je nach Zoomstufe und wie überrepräsentiert er gerne
Autobahnen möchte. OSM hat NIRGENDS eine Vorgabe wie breit ein
highway=unclassified ist.

Ich weiss nicht wie du drauf kommst das in OSM Linien eine Breite haben.

> > Korrekt - Die Mitellinie ist die Geometrische Mitte der Straße - Und die
> > erfassen wir. Dazu noch attribute der Straße - Mehr nicht.  
> 
> Sorry, aber das ist /deine/ Auffassung und vielleicht die ein paar anderer.
> Es ist so /nirgends/ dokumentiert und es ist auch nicht intuitiv (zumindest
> nicht, so lange der Flächenumriss nicht auch eingetragen ist - das ist noch
> lange nicht überall der Fall, auch wenn es in die Richtung geht, auf jeden
> Fall ist das ein Paradigmenwechsel).

https://wiki.openstreetmap.org/wiki/Good_practice#Keep_straight_ways_straight

"follow the central separation line between lanes in opposite directions
and add the relevant number of lanes in each forward/backward direction
for each section where the number of lanes changes"

Es ist alles seit >10 Jahren Dokumentiert das wir der zentralen
Mittellinie der Straße folgen. Das ist nicht MEINE Meinung das ist
Dokumentierte OSM Good Practice -  Kannst du zur Kenntnis nehmen
kannst es aber auch lassen und hier weiter trollen.

> Wir schrieben, dass eine Straße erfasst wird und die hat nunmal naturgemäß
> eine /Breite/, ob die nun explizit durch das width-Tag erfasst wird, oder
> mit größerem Fehler implizit durch lanes-Tags oder Klassifikationsattribute
> spielt weniger eine Rolle.

Auch die Lanes sind keine Breiteninformation - oder steht irgendwo das
eine lane 2,50m Breit ist? Nein - Explizit nicht weil soetwas noch viel
falscher wäre. Das einzige was eine valide Breite wäre wäre ein "width"
tag das aber vernachlässigbare verbreitung findet und auch von
keinem Datenkonsumenten ausgewertet wird.

> Es ist eine Frage der Datenverwendung, ob der Linienzug und die assozi-
> ierten Attribute zur Rekonstruktion der räumlichen Ausdehnung in 1, 2
> oder 3 Dimensionen verwendet werden.

Nein - Man kann keine Tangente an einen Punkt konstruieren.

> Das Routing-Engines nur die Ausdehnung in der Länge betrachten ist kein
> Grund zur Annahme, dass das Datenobjekt die Ausdehnung des geographisch-
> en Faktums in der Breite vernachlässigt.

Im Datenobjekt gibt es keine Breite - Wo siehst du die ? Mapnik
schummelt die da dran und das haben dir jetzt schon 3 Leute erklärt
und du weigerst dich dieses zur Kenntnis zu nehmen. Ich frage mich
langsam warum.

> > ich nicht einfach gedankenverloren Flächen an Wege geklebt weil das bei
> > egal welcher Genauigkeit einfach topologisch falsch ist und bleibt.
> 
> Ist es nicht.  Es ist maximal geometrisch ungenau, genau so ungenau, wie
> es eben ungenau ist, einen Weg als Linie und nicht als Fläche zu begreifen.

Du rundest eine absolute Position auf die nächste Straße - Damit ist
die absolute Position kaputt und zusätzlich topologisch falsch.

> > > Natürlich kann man das und es ist auch nicht so, dass das noch niemand 
> > > getan
> > > hätte oder die Algorithmen dazu nicht zur Verfügung stünden.  Ich habe 
> > > auch
> > 
> > Link? Referenz? 
> 
> Du kannst dich da beliebiger Extrusions-Algorithmen bedienen, also
> Algorithmen, die durch Parallelverschiebung der Kanten eines
> geometrischen 

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Christian Müller]

> Gesendet: Sonntag, 08. April 2018 um 09:56 Uhr
> Von: "Falk Zscheile" <falk.zsche...@gmail.com>
> An: "Openstreetmap allgemeines in Deutsch" <talk-de@openstreetmap.org>
> Betreff: Re: [Talk-de] Flächen/Wege // Trolling in changesets
>
> 1. Durch die snap-Funktion im JOSM lassen landuse und highway viel
> leichter verbinden, als wieder trennen. Dadurch haben die
> "Verschmelzer" beim Mappen einen taktischen und zeitlichen Vorteil
> gegenüber den "Trennern".

Das mag in einzelnen Fällen entscheidend sein, imho aber ist der
Bequemlichkeitsaspekt entscheidender. Zudem scheint das Entklebe-
verhalten maßgeblich von der Verfügbarkeit hoch aufgelöster Luft-
bilder abhängig zu sein.  Man kann also auch an diesen Luftbildern
"kleben", ohne dass dies per se sinnbehafteter wäre.


Gruß

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Christian Müller]

> Gesendet: Sonntag, 08. April 2018 um 19:16 Uhr
> Von: "Florian Lohoff" <f...@zz.de>
> An: "Christian Müller" <cmu...@gmx.de>
> Cc: talk-de@openstreetmap.org
> Betreff: Re: [Talk-de] Flächen/Wege // Trolling in changesets
>
> Ein Wasserweg bzw die Mitte dessen kann sehrwohl
> die Grenze darstellen. Eine Straße eher weniger (Hatte ich schon
> ausgeführt). Eine Straße kann aber nicht die Waldgrenze sein weil das
> bedingen würde das die Hälfte der Straße zum Wald gehört.

Oh, manchmal gehört die gesamte Straße zum Wald.  Alles eine Frage der
Perspektive und zeitlicher Entwicklungen:

A)  Die Baumkronen können die Straße vollends überdecken.

B)  Nach einem Unwetter, können zahlreiche Bäume auf der Straße liegen

C)  Auch Tiere gehören zum Wald, Tiere nutzen zeitweise die Straße, so
dass die strikten Übergänge verschwimmen.

D)  Forstarbeiter und Forstwirtschaftsmaschinen verwandeln die Straße
in einen Feldweg (ob saisonal oder über die Jahre).


> Hast du irgendeinen Beleg für? Ich bezweifle das stark. Der Normale mapper
> sieht nur nicht mehr was fehlt. Wenn du mir mal gegenden mit durchgehender
> sidewalk, shoulder, hazmat, maxspeed und lit mapping zeigst glaube ich das
> vielleicht.

Aber gerade das ist doch ein schönes Problem für eine gute Visualisierung,
die aufzeigt, wo solche Werte fehlen, oder eben lang nicht mehr bearbeitet
wurden.  Schwierig ist es, neue Mapper zu finden und zu motivieren.  Das
Problem teilt OSM mit Wikipedia.  Wenn die Leute dort ein paar Mal in einen
Editwar, Vandalismusdiskussionen und Admin-Gerichte über Relevanz verwickelt
waren, kommen sie halt nicht so schnell wieder oder senken Neugier und
Edit-Frequenz auf ein Minimum.


> Und in gegendenden in denen sich "jahrlang nichts mehr tut" ist die Karte
> so wie die in meiner E-Klasse von 2012 - Veraltet und echt nervig.

Ich finde es ganz gut, wenn ich von Zeit zu Zeit auf der Karte etwas
veraltetes entdecke.  Das motiviert von Zeit zu Zeit, etwas zu ergänzen.

Frustrierend ist doch eigentlich nur, wenn ein System so starr ist,
dass keine Edits möglich sind oder Kartenupdates erworben werden
müssen, wo dann immer noch die Hälfte fehlt.


Gruß

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Christian Müller]

> Gesendet: Sonntag, 08. April 2018 um 10:00 Uhr
> Von: "Florian Lohoff" <f...@zz.de>
> An: "Christian Müller" <cmu...@gmx.de>
> Cc: talk-de@openstreetmap.org
> Betreff: Re: [Talk-de] Flächen/Wege // Trolling in changesets
>
> Du scheinst aber hier dem Trugschluss aufzusitzen das OSM eine Karte
> ist. Das ist es nicht OSM ist und war nie eine Karte.

Du konntest unlängst selbst schlussfolgern, dass dieser Schein ein
Trugschluss ist, aber wenn man nur die Hälfte liest..


> OSM ist eine Sammlung von Geografischen Fakten. Die mit Mapnik erzeugte
> Karte ist nur ein Beispiel diese Sammlung an Fakten zu visualisieren.

Genau so, wie ein Routing-Graph /nur/ ein weiteres Beispiel ist, diese
Datensammlung zu benutzen.  Weder das eine noch das andere wird idealer-
weise bevorzugt.

Eigentlich ist es großer Mist, dass nur das credo
"Wir mappen nicht für Renderer."
so weit verbreitet ist, denn in gleicher Weise müsste sich
"Wir mappen nicht für Routing-Engines."
dazugesellen.

Und in beiden Statements müsste es lauten "nicht nur für".


> Wenn wir die Straße mit einer korrekten Breite erfassen
> dann gibt es für den Straßenabschnitt 2 Objekte. Die Mittellinie als
> geometrische Mitte der Straße mit allen Attributen wie
> Geschwindigkeitsbeschränkung etc und eine Objekt mit der Ausdehnung -
> Eine Highway Area.

Ja, das ist /jetzt/ so, /und/ es ist immer noch experimentell.  Es hat
sich noch nicht überall durchgesetzt, dass die Erfassung der highway
area sinnvoll ist; da gibt es noch viele Zweifelnde.

Historisch gesehen wurde eine Straße eigentlich nur dort mit Flächen-
umriss (also highway area) benutzt, wo eine konstante Breite des zu
erfassenden Objekts fehlte.


> Korrekt - Die Mitellinie ist die Geometrische Mitte der Straße - Und die
> erfassen wir. Dazu noch attribute der Straße - Mehr nicht.  

Sorry, aber das ist /deine/ Auffassung und vielleicht die ein paar anderer.
Es ist so /nirgends/ dokumentiert und es ist auch nicht intuitiv (zumindest
nicht, so lange der Flächenumriss nicht auch eingetragen ist - das ist noch
lange nicht überall der Fall, auch wenn es in die Richtung geht, auf jeden
Fall ist das ein Paradigmenwechsel).


> wievielten Mail zu sagen das wir bei Straßen ja eine Breite erfassen und
> das es schon okay ist Flächen damit zu verbinden weil man das ja "einfach raus
> rechnen kann". Und das ist halt in meinen Augen an so vielen Stellen 
> falsch das ich manchmal echt Baff bin. 

Es lässt sich rausrechnen mit abstraktionsbedingtem Fehler (Straßenweitungen
o.ä., Abschnitte nicht konstanter Breite über die Länge werden halt begradigt).
Dass es einfach ist habe ich nicht gesagt, denn das liegt im Auge des Be-
trachters, bzw. bei denjenigem, der es umsetzt.

Wir schrieben, dass eine Straße erfasst wird und die hat nunmal naturgemäß
eine /Breite/, ob die nun explizit durch das width-Tag erfasst wird, oder
mit größerem Fehler implizit durch lanes-Tags oder Klassifikationsattribute
spielt weniger eine Rolle.

Wir erfassen nicht die /Mittellinie der Straße/, sondern die Straße als
Linie.  Das ist nunmal ein Unterschied.

---
Das geographische Faktum, das erfasst wird, ist die Straße und /nicht/
deren Mittellinie, wie von dir oben behauptet.  Man hat sich entschieden,
dieses Faktum in der Datenbank als Linienzug zu /repräsentieren/.  Das
Faktum hingegen besitzt eine räumliche Ausdehnung in /Länge/, /Breite/
und /Höhe/, wie die eigentliche Mittellinie der Straße vor Ort im Übrigen
auch (aber die ist eben /nicht/ das modellierte Faktum!).
---

Es ist eine Frage der Datenverwendung, ob der Linienzug und die assozi-
ierten Attribute zur Rekonstruktion der räumlichen Ausdehnung in 1, 2
oder 3 Dimensionen verwendet werden.

Das Routing-Engines nur die Ausdehnung in der Länge betrachten ist kein
Grund zur Annahme, dass das Datenobjekt die Ausdehnung des geographisch-
en Faktums in der Breite vernachlässigt.

Ginge es nur darum, einen Routing-Graphen zu erstellen, könnte man sich
noch viel mehr Details sparen:  Dazu musst du die Straße eigentlich nur
mit Anfang- und Endpunkt und evtl. durch Punkte bei Geschwindigkeits-
wechseln erfassen und die Abschnitte dann mit der Distanz versehen bzw.
gewichten.  Dieser Anwendungsfall benötigt viel weniger geographische
Fakten, als in OSM erfasst werden / sind.


> Ein 1 Dimensionales Objekt kann nie eine reale Breite haben.

Was gleichzeitig bedeutet, dass ein 1-dimensionales Objekt nicht real
sein kann!?  Es ist eben eine Idealisierung, dass der Darstellung und
Speicherung von /Abbildern/ geographischer Fakten dient, die immer
eine räumliche Ausdehnung haben (und oft eine zeitliche noch dazu).

Selbst die Mittellinie der Straße hat im übrigen eine räumliche Aus-
dehnung in drei Dimensionen, aber dieser geographische Fakt wird

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Florian Lohoff]

On Sat, Apr 07, 2018 at 10:40:07PM +0200, "Christian Müller" wrote:
> Deine Argumentation basiert im großen Teil darauf, dass es eine Last wäre,
> Bestandsdaten zu editieren, wenn um die Neudaten herum, schon Bestand ex-
> istiert, der miteditiert werden muss.  Niemand zwingt Mappende, bei OSM

Verklebte Daten zu editieren ist eine große Last ja.


> Du hängst dich zwar an dem "Verklebt-Sein" zwischen linearen und arealen
> Objekten auf, aber die Implikation ist viel weitreichender:  Die Grenzen
> von Ländern und Bundesländern waren recht zeitig gemappt (ohne "unschöne"
> Lücken an den Landesgrenzen - weiß nicht, ob du auch dort Lücken lassen
> würdest).  Diese Grenzen aber bilden Flächen.  Der Leerraum oder der
> "weiße Fleck" den du also auf hoher Zoomstufe identifiziert haben wolltest,
> war zu diesem Zeitpunkt schon längst von einer Fläche überstrichen, zu
> dem Du in diese Fläche eine weitere eingezeichnet hattest.  Quizfrage:

Du ziehst hier ein Beispiel heran um das es nicht geht. Grenzen sind ein
absoluter Sonderfall. Ein Wasserweg bzw die Mitte dessen kann sehrwohl
die Grenze darstellen. Eine Straße eher weniger (Hatte ich schon
ausgeführt). Eine Straße kann aber nicht die Waldgrenze sein weil das
bedingen würde das die Hälfte der Straße zum Wald gehört.

Das am Beispiel einer Grenzrelation zu machen ist so ein bischen Äpfel
mit Birnen zu vergleichen und war auch nicht bestandteil 
der Verklebediskussion.

> Die "Last" Flächen neu zu mappen oder umzumappen entsteht regelmäßig
> u.a. dann, wenn ein Paradigmenwechsel durch Wiki oder Mailingliste
> fegt, und dazu führt, dass Daten, die früher unter einem anderen
> Paradigma eingetragen wurden, plötzlich ihre Gültigkeit verlieren
> (beispielhaft weil Teiche in einem Forst nicht mehr Teil der Forst-
> fläche sein sollen und als 'inner' von umliegenden Waldflächen aus-
> genommen werden, etc. pp.).  

Die Last entsteht immer dann wenn sich eines der verklebten Elemente
ändert, das andere jedoch nicht. D.h. z.b. ich will die Ackerfläche verkleinern
um einen Straßengraben anzufügen. Dann habe ich ein vielfaches des
aufwandes weil ich jeden node "unglueen" muss - dann die ja typischerweise
mind. 3 nodes sortieren (Straße, rechter und linker landuse) und dann ggfs
2 der nodes wieder verschmelzen.

Und das volldesaster entsteht dann wenn ein Mapper nichtmal merkt das es dort
verklebungen gibt. Das kommt relativ häufig vor.  Dann wird zwar ein node
weggezogen auf eine vermeindlich bessere lage, das passt aber dann nicht mehr
zu einem der verbundenen Objekte.  Der Nächste Mapper sieht im Luftbild ein
Objekt zu dessen Form es aber kein OSM Objekt mehr gibt und malt es drüber.

Das ist quasi bei dem Aufräumen eine Tägliche Routine. Doppelt und Dreifach
übereinander und verklebte Gebäude, Parkplätze etc.

> Ich stimme hier mit dir überein, ich sehe es auch ungern, wenn ungeduldige
> Mapper gigantische Flächen mit einem einzigen Tag beschreiben, nur damit
> die Karte nicht mehr weiß ist.  Allerdings sehe ich es nicht als Problem
> an, solche Flächen zu überarbeiten - in Iteration lassen sich in eine
> solche Fläche (ähnlich den oben erwähnten Ländergrenzen) kleinere Objekte
> einzeichnen ("mit Lücken dazwischen"), die dann mit der Zeit verbunden
> und in Relation gesetzt werden.  Dabei kann es vorkommen, dass vorher
> eingetragene Flächengrenzen segmentiert werden.

Das ist aber gigantisch viel aufwendiger wenn das noch alles verklebt ist.
Mal davon abgesehen das die ursprüngliche Fläche auch "mapping für den renderer"
ist was explizit unerwünscht ist.

> Eine detaillierte Karte entsteht nicht über Nacht, das braucht Zeit.
> Ob in der Zwischenzeit Details von Monsterflächen verdeckt werden,
> die dann wieder verschwinden (oder als benannte, komplexe Fläche
> mit Teilflächen, z.B. Muskauer Park fortbestehen), ist doch im Grunde
> weniger wichtig.

Es ist extrem wichtig. Denn solche gigantischen Flächen fast niemand mehr an. 
Die werden gemapped und ich sehe das die 10 Jahre Später quasi unverändert
da noch rumschimmeln weil sich da keiner dran traut. Das ist eines der 
Folgeprobleme
des verklebens. Es erhöht die komplexität der vorhandenen Daten und damit
sinkt die wahrscheinlichkeit der weiteren Pflege.

> Das kann man so pauschal nicht sagen.  Wäre es so dramatisch, wie du es
> darstellst, gäbe es viel weniger Nutzung etablierter Tags und wesent-
> lich häufiger Streit um irgendwelche Changesets.  Die Änderungsdichte

Normative Kraft des faktischen. Menschen wollen das die gerenderte Karte schön
aussieht also wird gemapped und getagged was funktioniert.
OSM hat ein typischer EDV Problem auf den Kopf gestellt. Nicht die Eingabe 
validiert
und bestimmt das schema sondern die weitere verarbeitung. Wenn ich möchte das
meine Adresse in Nominatim auftaucht muss ich das Karlsruhe Schema nehmen.

> wäre schlicht eine größere, aber in vielen Gebieten tut sich schon
> jahrelang nichts (wesentliches) mehr, weil die Daten, so wie sie ein-
> getragen sind, weitgehend 

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Martin Koppenhoefer]

> On 8. Apr 2018, at 10:00, Florian Lohoff  wrote:
> On Sun, Apr 08, 2018 at 02:57:34AM +0200, "Christian Müller" wrote:
>>> Gesendet: Sonntag, 08. April 2018 um 00:43 Uhr
>>> Von: "Florian Lohoff" 
>> 
>> Wenn das width-tag fehlt, wird je nach
>> Straßenklasse und evtl. dem lanes-Attribut eine Breite errechnet.


sorry, errechnet wird da dann gar nichts, es wird geraten / geschätzt, weil man 
ja auch mit lanes getaggt keine Angaben zur Spurbreite hat, genauso wenig wie 
Straßenklassen feste Breiten haben.



> 
> Nur und ausschliesslich im Renderer und das auch nur Renderer Spezifisch
> und das auch in Pixeln je nach Auflösung - Mit der realen Breite hat und
> hatte das nie zu tun.
> 


es war mit mapnik lange Zeit nicht möglich, Stileigenschaften parametrisch zu 
definieren (z.B. die Linienbreite aus der Datenbank zu nehmen), soweit ich weiß 
geht das jetzt aber. In Qgis geht es z.B. sicher.



> Ein 1 Dimensionales Objekt kann nie eine reale Breite haben. Die wird an
> den Stellen wo die Straße angezeigt wird nur dazu geschummelt. Mit Real
> erfasster Breite hat und hatte das nie zu tun und wird es auch nie zu
> tun haben. Wenn du eine Reale Fläche/Breite haben willst musst du das
> als Fläche separat erfassen.



solange die Breite unverändert gleich bleibt geht es schon mit einer Linie und 
Breitenangabe, nur wenn die Breite sich halt ändert wird es schwierig. Plätze 
waren in OSM z.B. historisch sehr lange schlecht repräsentiert/abbildbar, quasi 
waren sie zunächst vergessen worden, weil es eben um die Verbindungen ging, und 
weniger um die Form.


> Hat aber auch alles nichts mit der Genauigkeit zu tun. Auch damals habe
> ich nicht einfach gedankenverloren Flächen an Wege geklebt weil das bei
> egal welcher Genauigkeit einfach topologisch falsch ist und bleibt.



so hart würde ich es nicht sagen, weil man m.E. durchaus auch für das Verbinden 
argumentieren könnte, wenn es vorwiegend um ein vereinfachtes Topologiemodell 
ginge und man keine Details unterhalb des landuse levels hätte und wollte.

Ich kenne OSM auch noch aus Zeiten vor der Verfügbarkeit von guten Luftbildern, 
als man noch ausschließlich mit Notizen, Fotos und GPS gearbeitet hat, bzw. gab 
es schon grobpixelige Yahoo bilder mit zig Metern Lageungenauigkeit (und es gab 
Mapper, die alles mühsam erarbeitete auf diesen Luftbildern „zurechtschob“, 
ähnlich wie heute mit Bing, nur auf anderem Video), und ich war auch damals 
schon dagegen , beim Flächenzeichnen eine Abkürzung zu nehmen, von der klar 
war, dass sie das Eintragen von weiteren Details ziemlich erschweren würde.


>> (OSM war
>> /ist ein Hobbyprojekt, ein Projekt von und für die crowd nicht wahr?)
> 
> Also bisher hatte ich immer (>10 Jahre) die Möglichkeit auf Rechnern zu
> Arbeiten die die OSM Daten verarbeiten konnten. Ich habe lange für QA
> Zwecke OSRM Instanzen laufen gehabt die den ganzen Tag routen getestet
> haben etc. Ich habe mal ein auf PostgreSQL/PostGIS basierendes Datenbankend 
> für 
> osmarender gebaut. So abwegig ist das mit den OSM Daten zu arbeiten nicht.


+1, es ist (war) eher die Komplexität der einzelnen tools und Abhängigkeiten 
und der Aufwand, alles mögliche einzurichten, die viele m.E. davon abgehalten 
haben, selbst Dinge mit den Daten zu machen, als die Hardwareanforderungen. 
Hobbyisten haben meistens keinen Bedarf an weltweiten detaillierten Daten, 
vielen reicht ein regionales Gebiet aus für ihre Bedürfnisse (danke Geofabrik 
und andere), und das dauert selbst auf schmalbrüstiger, veralteter 
Konsumerhardware nicht soo lang, das durchzuwursten.

Auch wenn für sich genommen die einzelnen Schritte nicht so schwer sind, so 
sind es oft doch einige. Es gibt und gab aber immer auch schon rel. simple 
tools (in der Bedienung ) mit denen man schon sehr viel machen kann, z.B. 
maperitive, osmarender, overpass turbo, und mittlerweile sind auch klassische 
GIS tools wie QGis gut auf OSM vorbereitet.


> 
>> Das Verkleben ist im Hinblick darauf, die Größe der DB klein zu halten,
>> heute scheinbar nicht mehr so wichtig.  Vor zehn Jahren gab es schon noch
>> ein paar mehr Leute, denen es wichtig war, dass die Gesamtdaten auch auf
>> kleine Geräte passten und dort verarbeitbar waren.  


um die Daten auf kleine Geräte zu packen kann man sie bearbeiten / filtern und 
bei Bedarf die Genauigkeit reduzieren. Das sollte kein Argument sein, um 
absichtlich weniger in die db einzutragen als man eigentlich gut fände.


Gruß,
Martin 
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[mmd]

Am 05.04.2018 um 11:38 schrieb Florian Lohoff:

> On Wed, Apr 04, 2018 at 07:54:30PM +0200, Michael Reichert wrote:

>> Ich bin sehr daran interessiert, die Abstimmung mit den Füßen
>> auszuwerten, und würde mich freuen, wenn du deinen Code entweder mir zur
>> Verfügung stellen könntest oder gleich als freie Software
>> veröffentlichen könntest. Die Auswertung ist nicht ganz einfach, weil
>> man weder einfach die Objekte noch die Länge noch den Flächeninhalt
>> zählen muss, sondern auch beachten muss, wer was beigetragen hat.

> Was ich mache ist das ich mir für jeden node merke welche Wege attached
> sind. Dann gehe ich alle Wege durch (Nur die lines - also high und
> waterway) und gucke ob an 2 aufeinanderfolgenden nodes jeweils eine
> area mit derselben ID attached ist.

Netter Testfall. Ich habe mal versucht, das ganze soweit möglich mit
Turbo nachzustellen, allerdings mit der vereinfachten Annahme, dass ein
highway=* und landuse=* Way mindestens 2 gemeinsame Knoten haben müssen.
Das mit dem aufeinander folgend lässt sich leider nicht so recht abbilden.

Den Link zur Query habe ich auf folgende Github-Seite ausgelagert, weil
sich in diesem Medium nachträglich kein Post mehr ändern lässt.

https://github.com/drolbr/Overpass-API/issues/467#issuecomment-379536822

-- 





___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Florian Lohoff]

Hola,

On Sun, Apr 08, 2018 at 02:57:34AM +0200, "Christian Müller" wrote:
> > Gesendet: Sonntag, 08. April 2018 um 00:43 Uhr
> > Von: "Florian Lohoff" <f...@zz.de>
> > An: "Christian Müller" <cmu...@gmx.de>
> > Cc: talk-de@openstreetmap.org
> > Betreff: Re: [Talk-de] Flächen/Wege // Trolling in changesets
> >
> > Ich habe mehrfach das Gegenteil behauptet und dafür auch klare
> > Grundlagen genannt - Ich sehe einfach nicht den Vorteil für eine 
> > Minderheit (Nachweis siehe vorangegangene Mail) die kein "Nichts" in der
> > Karte sehen will, allen Flächen absichtlich Fehler
> > Geographischer und Topologischer Natur hinzuzufügen und es dazu für
> > Neumapper nahezu unmöglich zu machen korrekte Daten zu erfassen.
> 
> Irgendwie liest du auch nur das, was du lesen willst, oder?  Da
> brauchst du dich dann auch nicht wundern, wenn niemand die von dir
> verschickten Dokus liest.  Wenn das width-tag fehlt, wird je nach
> Straßenklasse und evtl. dem lanes-Attribut eine Breite errechnet.

Nur und ausschliesslich im Renderer und das auch nur Renderer Spezifisch
und das auch in Pixeln je nach Auflösung - Mit der realen Breite hat und
hatte das nie zu tun.

Du scheinst aber hier dem Trugschluss aufzusitzen das OSM eine Karte
ist. Das ist es nicht OSM ist und war nie eine Karte. 

OSM ist eine Sammlung von Geografischen Fakten. Die mit Mapnik erzeugte
Karte ist nur ein Beispiel diese Sammlung an Fakten zu visualisieren.

> Das eine genaue Angabe oft fehlt, ist ein Missstand, rechtfertigt
> aber nicht die Annahme, dass wir nur die Mittellinie von Straßen
> erfassen.  Das geographische Objekt, dass von einem mit highway=*

"Nur" habe ich nie behauptet - Du hast behauptet das wir die Mittellinie
nicht erfassen sondern ein Objekt mit Breite - Bei einem 1 Dimensionalen
Objekt ist diese Annahme - aehm - schwer nachzuvollziehen. Das stimmt so
einfach nicht. Wenn wir die Straße mit einer korrekten Breite erfassen
dann gibt es für den Straßenabschnitt 2 Objekte. Die Mittellinie als
geometrische Mitte der Straße mit allen Attributen wie
Geschwindigkeitsbeschränkung etc und eine Objekt mit der Ausdehnung -
Eine Highway Area.

> getaggten Datenbankobjekt repräsentiert wird, ist eine Straße,
> mit Straßenfläche und ggf. weiteren Eigenschaften, nicht diese
> Mittellinie.  Wir erfassen die Straße als Mittellinie, nicht umge-

Wir nennen es Straße - Geometrisch ist es die Mittellinie - und wir
erfassen viel - Aber die Breite eben nur auf einem verschwindend
geringen teil der Wege. 

> kehrt.  Nach deiner Argumentation müssten ja die Seitenstreifen,
> Trennlinien, Standstreifen nochmals als Idealisierung in den Daten-
> bestand, weil die Mittellinie nur für sich steht, steht sie aber
> nicht.  Es wurde sowohl im Wiki als auch in der Mailingliste
> mehrmals darauf hingewiesen, dass Spuren und Standstreifen /nicht/
> separat erfasst werden, /weil/ die Mittellinie die baulich nicht
> getrennte Straßen/fläche/ repräsentiert.

Korrekt - Die Mitellinie ist die Geometrische Mitte der Straße - Und die
erfassen wir. Dazu noch attribute der Straße - Mehr nicht.  

> Ich verstehe auch nicht, wieso du dich von einer Erklärung zur Situation
> der Bestandsdaten angegriffen fühlst.  Ich habe auch nie behauptet, dass
> ich irgendeinen Fehler hinzufügen will, in der Art, wie du ihn beschreibst.
> Es ging darum aufzuzeigen /warum/ diese Daten so in der DB zu finden sind,
> wie sie es sind.

Umgekehrt wird ein Schuh draus - Du versuchst mir in der ich weiss nicht
wievielten Mail zu sagen das wir bei Straßen ja eine Breite erfassen und
das es schon okay ist Flächen damit zu verbinden weil man das ja "einfach raus
rechnen kann". Und das ist halt in meinen Augen an so vielen Stellen 
falsch das ich manchmal echt Baff bin. 

Ein 1 Dimensionales Objekt kann nie eine reale Breite haben. Die wird an
den Stellen wo die Straße angezeigt wird nur dazu geschummelt. Mit Real
erfasster Breite hat und hatte das nie zu tun und wird es auch nie zu
tun haben. Wenn du eine Reale Fläche/Breite haben willst musst du das
als Fläche separat erfassen.

> Vielleicht war das ja bei dir schon immer so, dass du mit 2cm genauen Luft-
> bildern gemappt hast.  Ich hingegen kenne OSM noch aus einer Zeit, wo für
> das hiesige Gebiet keine sonderlich gute Auflösung mit den Quellen zur Ver-
> fügung stand, die zur Nutzung mit OSM erlaubt waren.

Ich komme aus NRW und ja - wir hatten früh und lange Zugriff auf 40cm
Luftbilder - Erst über das LVermA jetzt über ESRI. 

Und ich kenne OSM noch aus Zeiten da ich mit einem Feldbuchrahmen
rum gerannt bin und zu meinen GPS Tracks noch Zeichnungen gemacht habe.

Hat aber auch alles nichts mit der Genauigkeit zu tun. Auch damals habe
ich nicht einfach gedankenverloren Flächen an Wege geklebt weil das bei
egal welch

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Falk Zscheile]

Ich möchte das ganze im Folgenden versuchen ein wenig auf eine
Meta-Ebene zu heben, möchte aber nicht verhelen, dass ich auf
highway=value geklebte landuse=value nicht mag bzw. ablehnend
gegenüber stehe. Aber auch ich habe mal als "Verkleber" angefangen:

Abgesehen von der Sinnhaftigkeit (keine Metaebene) gibt es auf der
Metaebene folgende Aspekte:

1. Durch die snap-Funktion im JOSM lassen landuse und highway viel
leichter verbinden, als wieder trennen. Dadurch haben die
"Verschmelzer" beim Mappen einen taktischen und zeitlichen Vorteil
gegenüber den "Trennern".

2. Das getrennte erfassen erfordert mehr Genauigkeit. Man muss viel
weiter hineinzoomen, um Flächen zu erfassen, damit man nicht selbst
"Opfer" der snap-Funktion von JOSM wird. Man hat also einen kleineren
Kartenausschnitt auf dem Bildschirm. Hierdurch benötigt man mehr Zeit
und muss trotzdem aufpassen (wegen der snap-Funktion). Auch Mapper
sind sind nur Menschen, also bequem und möchten trotzdem viel pro
Zeiteinheit schaffen. Auch das ist ein strategischer Nachteil der
getrennten Erfassung. Die Verschmelzer sind faktisch im Vorteil, weil
sie mehr pro Zeiteinheit Mappen können. Dann können sie ggf. auch noch
sagen, "Seht her, in den Daten ist viel mehr verklebt als getrennt!
Wir sind die Mehrheit, wir haben Recht!"

3. Durch das verschmelzen sieht die Datenbasis im JOSM auch besser --
weil aufgeräumter wirkend -- aus, als mehrere parallele Linien. Man
sollte diesen ästhetischen Aspekt nicht vernachlässigen. Wir sind ein
Projekt, das von Laien getragen wird. Da spielen solche Aspekte eine
viel größere Rolle, als in einem professionellen Umfeld mit
festgefügten Regeln und Normen (wir müssen Regeln und Normen erst
finden und ständig darüber diskutieren).

4. Menschliches Beharrungsvermögen: Niemand gibt gern Gewohnheiten
auf. Warum sollte also ein "Verschmelzer" sich ändern? Zumal der
Verschmelzer merkt, dass die andere Methode aufwendiger ist und mehr
Sorgfalt erfordert. (Vielleicht liegt die Sorgfalt auch nicht so in
seiner Natur, wogegen die "Trenner" eher von pingeliger Natur sind).

5. Eine eigene Ausprägung von Beharrungsvermögen ist: Die Arbeit des
"Verschmelzers", das Verschmelzen, wird ein Stück weit entwertet, wenn
jetzt immer getrennt werden soll. Niemand sieht seine Arbeit gern
entwertet und wird daher immer alles versuchen, diese zu erhalten und
gegen Änderungen zu verteidigen.

6. Eine weitere Ausprägung des Beharrungsvermögens findet sich auch
bei der Regeldiskussion "das ist so nicht/anders Dokumentiert".
Einerseits sind Regeln sehr wichtig, weil erst sie eine Basis geben,
auf der man gemeinsam arbeiten kann. Andererseits ändern sich die
Gegebenheiten, auf denen die Regeln basieren. Vor fünf Jahren war man
froh ein einigermaßen vollständiges Straßennetz (DE) zu haben. Da
wollte man nicht über Straßenflächen diskutieren und gab sich
entsprechende Regeln. Doch warum sollen die Regeln heute noch gelten?
Die Regeln bei OSM sind ja nicht die (universell gültigen)
Menschenrechte. Also: geänderte Situation, geänderte Regeln. Das
Problem: Man erkennt quasi immer nur in der Retrospektive, ob sich die
Situation tatsächlich geändert hat. Da also niemand aus der Zukunft
zurückblicken kann, entstehen solche langen Threads zwischen
"Verklebern" und "Trennern".

Daraus folgt für mich auf der Handlungsebene:

Bei den Punkten 1. bis 3. muss auf Ebene der Werkzeuge zunächst
Waffengleichheit zwischen Verklebern und Trennern hergestellt werden!

Bei den Punkten 1. bis 3. wünsche ich mir einfach einen mutigen
Entwickler, der eine Warnung einbaut, wenn landuse als Fläche und
highway als way miteinander verbunden werden sollen. Problem: Wir
zeichnen erst die Geometrie und geben dann die Eigenschaften/Tags.
Aufgrund meiner Grundauffassung sollte das überhaupt nicht möglich
sein bzw. um den Verschmelzern nicht auf die Füße zu treten nur als
"opt in". Dann wäre zumindest was die Schwierigkeit angeht
einigermaßen Waffengleichheit hergestellt und neue Mapper kommen nicht
mehr so leicht in Versuchung zum "Verkleber" zu werden.

Eine schöne Lösung wäre es auch, wenn die snap-Funktion bei highways
nicht funktionieren würde (zumindest nicht für ways, die noch keine
Tags haben und generell nicht für landuse auf highway).

Wichtig ist, dass man das snap-Verhalten von landuse auf highway (way)
in der Grundfunktion abstellt, damit die Leute gar nicht erst
"klebstoffsüchtig" [Entschuldigung für den Kalauer] werden. Dann
stellen sich die Probleme aus Nr. 4 bis 6 nicht in gleichem Maße. Dann
erledigt sich das Problem in einem gewissen Maß von selbst. "Es wächst
sich raus."

Eine andere Möglichkeit ist es endlich handliche Tools zu entwickeln,
die das Entkleben genauso einfach machen, wie das Verkleben. Das hat
aber die große Gefahr von "edit wars".

An den Punkten 4. bis 6. kann man ansonsten in einem
Freiwilligenprojekt nicht viel ändern, außer vielleicht, das die
Beteiligten selbst Reflektieren, mal was anderes ausprobieren und dann
zu dem Ergebnis kommen "ist ja gar 

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Christian Müller]

> Gesendet: Sonntag, 08. April 2018 um 00:17 Uhr
> Von: "Martin Koppenhoefer" <dieterdre...@gmail.com>
> An: "Openstreetmap allgemeines in Deutsch" <talk-de@openstreetmap.org>
> Betreff: Re: [Talk-de] Flächen/Wege // Trolling in changesets
>
> width ist nur eine (dazuhin kaum erfasste) Eigenschaft der Linie, um die 
> Fläche, die damit beschrieben werden soll, geht es im OSM Modell für highway 
> aber praktisch nicht, was man z.B. daran sieht, dass man z.B. zwar 
> Spuranzahlen erfasst, aber normalerweise nicht wie breit die Spuren sind oder 
> wie sie am Anfang und Ende ineinander übergehen und wo und wielange diese 
> Übergänge sind, oder wo quergestreifte Teilflächen sind, oder wo es breitere 
> und engere Stellen gibt, wo Schlaglöcher liegen, etc (teilweise wurde das mit 
> dem lanes-tagging nachträglich etwas verbessert). Nüchtern betrachtet gibt es 
> (gab es lange) praktisch keine tags um die Fläche einer Straße oder eines 
> Wegs zu beschreiben, weil alles auf eindimensionale Verbindungen ausgerichtet 
> war.

Diese Antwort dokumentiert teilweise den Paradigmenwechsel von dem ich spreche, 
aber auch Sichtweisen die so nie dokumentiert waren und hier nachgereicht 
werden (..), was aber so nicht gut funktioniert, da zahlreiche Mapper die 
Daten, die sie vorgefunden haben, unlängst anders interpretiert haben/hatten.  
Diese andere Interpretation ist weit entfernt von unlogisch oder falsch und sie 
liefert eine plausible Erklärung für die Existenz verklebter Objekte.  Hätte 
man das frühzeitig vermeiden wollen, hätte früh dokumentiert werden müssen, 
dass bestimmte Linien "heilig" sind, in dem Sinne, dass sie ausschließlich für 
Längenberechnungen und Routingzwecke verwendet werden dürfen.  Diese 
Restriktion gab es aber nie.

De facto war es sogar so, dass lange Zeit Umrissflächen von Straßen und 
Kreuzungen wieder aus der DB entfernt wurden, mit dem Argument, dass diese 
durch die Mittellinie bereits bestens erfasst seien und man keine Redundanzen 
wolle.  Das hat sich durch die Akzeptanz der Straßenumrisse (area:highway o.ä.) 
etwas verlagert, aber die Sichtweise darauf war eben mal eine andere.  Wenn man 
beides akzeptiert, lässt sich natürlich in vielen (allen?) Fällen darauf 
verzichten, angrenzende Flächen mit der Mittellinie zu beschreiben, weil /dann/ 
die Flächengrenze des Straßenumrisses verwendet werden kann.  Die Bedenken die 
dahingegehend geäußert wurden sind m.M.n. aber nach wie vor gültig - das hängt 
alles an der Verfügbarkeit gut georeferenzierter und gut aufgelöster 
Luftbilder.  Fallen die weg, wird die Datenpflege der Straßenflächenumrisse 
u.U. so aufwendig, dass diese wieder von der Mittellinie idealisiert werden 
werden (ob mit genauer oder ungefährer Breite der Klassifikation nach).


Wenn wir dazu ein paar mehr Stimmen hören würden, ließe sich evtl. mit Konsens 
im Wiki dokumentieren, dass Nachbarflächen von Straßen nach Möglichkeit mit 
einer die Mittellinie umgebenden Geometrie vernäht werden sollen.  Ich sehe 
aber in Gebieten, in
denen Luftbilder als Referenz fehlen, dann nach wie vor das Problem, das zwar 
eine ungefähre Straße mit GPS-Daten beigetragen werden kann, nicht aber mit 
Zuversicht deren Umriss (wenn er nicht mit JOSM 'konstruiert' wird).  Die Doku 
müsste dann also darauf eingehen, wie Mapper vorgehen sollen, wenn sie die 
Straßenflächengrenze nicht aus Luftbildern extrahieren können:  Ist die 
Konstruktion einer angenommenen Straßenbreite dann erlaubt / nur wenn sie 
tatsächlich bekannt ist / oder nie, mit der Maßgabe, dass dies mit dem 
Verfügbarwerden von Luftbildern nachgetragen werden könne.

In solchen Regionen ist die Wiederverwendung der Mittellinie nämlich deshalb 
interessant, weil die Zuversicht, eine genaue Straßenflächengrenze angeben zu 
können, fehlt.  Wenn Luftbilder ungengau ausgerichtet sind, trifft das aber 
imho auch z.B. in D zu.


Gruß,
cmuelle8

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Christian Müller]

> Gesendet: Sonntag, 08. April 2018 um 00:43 Uhr
> Von: "Florian Lohoff" <f...@zz.de>
> An: "Christian Müller" <cmu...@gmx.de>
> Cc: talk-de@openstreetmap.org
> Betreff: Re: [Talk-de] Flächen/Wege // Trolling in changesets
>
> Ich habe mehrfach das Gegenteil behauptet und dafür auch klare
> Grundlagen genannt - Ich sehe einfach nicht den Vorteil für eine 
> Minderheit (Nachweis siehe vorangegangene Mail) die kein "Nichts" in der
> Karte sehen will, allen Flächen absichtlich Fehler
> Geographischer und Topologischer Natur hinzuzufügen und es dazu für
> Neumapper nahezu unmöglich zu machen korrekte Daten zu erfassen.

Irgendwie liest du auch nur das, was du lesen willst, oder?  Da
brauchst du dich dann auch nicht wundern, wenn niemand die von dir
verschickten Dokus liest.  Wenn das width-tag fehlt, wird je nach
Straßenklasse und evtl. dem lanes-Attribut eine Breite errechnet.
Das eine genaue Angabe oft fehlt, ist ein Missstand, rechtfertigt
aber nicht die Annahme, dass wir nur die Mittellinie von Straßen
erfassen.  Das geographische Objekt, dass von einem mit highway=*
getaggten Datenbankobjekt repräsentiert wird, ist eine Straße,
mit Straßenfläche und ggf. weiteren Eigenschaften, nicht diese
Mittellinie.  Wir erfassen die Straße als Mittellinie, nicht umge-
kehrt.  Nach deiner Argumentation müssten ja die Seitenstreifen,
Trennlinien, Standstreifen nochmals als Idealisierung in den Daten-
bestand, weil die Mittellinie nur für sich steht, steht sie aber
nicht.  Es wurde sowohl im Wiki als auch in der Mailingliste
mehrmals darauf hingewiesen, dass Spuren und Standstreifen /nicht/
separat erfasst werden, /weil/ die Mittellinie die baulich nicht
getrennte Straßen/fläche/ repräsentiert.

So einseitig wie du die Sache hier darstellst, ist das Projekt nicht.
Wir erfassen keinen Graphen, nicht primär. Routing war schon immer
/ein/ Aspekt, ein Anwendungsfall, der sich mit den gesammelten Daten
befrieden lässt, nicht der Einzige.  Die Ziele mit denen Freiwillige
Daten ergänzt haben, sind divers.  Hier ist jeder seine eigene Minder-
heit und ich glaube kaum, dass du die zahlreichen Anwendungsfälle alle
überblickst.

Ich verstehe auch nicht, wieso du dich von einer Erklärung zur Situation
der Bestandsdaten angegriffen fühlst.  Ich habe auch nie behauptet, dass
ich irgendeinen Fehler hinzufügen will, in der Art, wie du ihn beschreibst.
Es ging darum aufzuzeigen /warum/ diese Daten so in der DB zu finden sind,
wie sie es sind.

Vielleicht war das ja bei dir schon immer so, dass du mit 2cm genauen Luft-
bildern gemappt hast.  Ich hingegen kenne OSM noch aus einer Zeit, wo für
das hiesige Gebiet keine sonderlich gute Auflösung mit den Quellen zur Ver-
fügung stand, die zur Nutzung mit OSM erlaubt waren.


> Man kann das eben genau nicht raus rechnen oder "Mal eben Algorithmisch
> Lösen" - Diesen Beweis sind bisher alle die das behauptet haben schuldig
> geblieben.

Natürlich kann man das und es ist auch nicht so, dass das noch niemand getan
hätte oder die Algorithmen dazu nicht zur Verfügung stünden.  Ich habe auch
nie behauptet, dass das fehlerfrei möglich sei, und ich wiederhole mich, wenn
ich dir erkläre, dass Speicherplatz und Verarbeitungsbreite für geographische
Daten in der Breite noch nicht seit Ewigkeiten zur Verfügung stehen. (OSM war
/ist ein Hobbyprojekt, ein Projekt von und für die crowd nicht wahr?)

M.M.n. differenzierst Du Vergangenheit/Gegenwart nicht genügend, und nutzt
heute gültige Argumente, um dein Unverständnis gegenüber einer Datenlage
auszudrücken, die unter anderen Paradigmen entstanden ist. Paradigmenwechsel
und teilweise auch die offene Paradigmensuche, die das Projekt durchgangen
hat und die der Grund dafür sind, dass es ein Großteil der Mapper heute
bevorzugt, luftbildgenau abzuzeichnen, anstatt mit Papier oder GPS vor Ort
Daten zu erfahren, zu erfassen und später in der DB abzubilden, blendest
du in diesem Thread warum auch immer aus.

Das Verkleben ist im Hinblick darauf, die Größe der DB klein zu halten,
heute scheinbar nicht mehr so wichtig.  Vor zehn Jahren gab es schon noch
ein paar mehr Leute, denen es wichtig war, dass die Gesamtdaten auch auf
kleine Geräte passten und dort verarbeitbar waren.  In dieser Zeit ist die
Erklärung für manche Bestandsdaten viel einfacher zu suchen und zu finden.

Ein geometrischer Fehler von auch 3 - 5 Metern ist/war für viele Anwend-
ungsfälle völlig unerheblich, ob du das nun wahrhaben willst oder nicht. Du
schriebst, nach meiner Erfahrung zutreffend, dass Gemeinden z.B. früher nur
als Node eingetragen waren.  Gehst du die Minderheiten, die das heute noch
tun auch an, nur weil du der Meinung bist, dass sie die Gemeinde ja gleich
umrisshaft hätten einzeichnen können?  Bist du der Meinung, dass die un-
genauen Siedlungsgrenzen wertlos sind? - Deren Fehler ist auch mit modernen
Luftbildern erheblich und er wird dennoch akzeptiert, weil eine ungefähre
Siedlu

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Florian Lohoff]

Hola,

On Sat, Apr 07, 2018 at 11:51:2O8PM +0200, "Christian Müller" wrote:
> > Nein - Wir behaupten das ein Knoten an der Absoluten Position 51.434
> > 8.123 ist - Und nicht - An dieser Stelle -8m/2 rechtwinkelig zu einem
> > der Wegen die diesen Knoten enthält. Das machen wir NIRGENDS bei OSM.
> > 
> > OSM ist eine Sammlung von Geografischen Fakten - Und das ist dann eben
> > kein Faktum sondern evtl. eine Konstruktionshilfe.
> 
> Das ist nett gedacht, aber diese Argumentation funktioniert hinten und
> vorne nicht, weil die Mittellinie /nicht als Faktum/, sondern selbst
> als Konstruktionshilfe eingetragen wird.

Nein - die Mittellinie ist die Orientierung für die Erfassung eines
Graphen zwecks Routing. Zusätzlich die Angabe für den Renderer wo
in eine möglicherweise auszugebenden Karte die Mitte der zu Rendernden
Linie ist.

> Wir erfassen ja mit der Mittellinie eben /nicht/ die Mittellinie sondern
> ein geographisches Objekt mit einer Breite.  Das man das auch als Linie
> in einem Routing-Graphen /verwenden/ kann, ist ein anderer Aspekt, aber
> sowohl das Datenmodell, als auch die width-Tags sprechen eine klare,
> andere Sprache:  Das Faktum ist die Wegfläche, ihre Kodierung die /ange-
> näherte/ Mittellinie.

Das genau steht wo? Ein "width=" ist eine "useful combination" auf einem Weg
und mitnichten verpflichtend oder auch nur häufig angewendet. Und ein
Objekt mit nur 1ner Dimension kann schlecht eine Breite haben.

Das tag width= findet sich 1.5Mio mal in der OSM Datenbank. Stand Ende
2017 hatten wir 430Mio Ways. D.h. auf gerade mal 0.25% der Wegen ist
eine Breitenangabe. Da halte ich die Aussage "wir erfasssen ... Objekt
mit einer Breite" für geradezu abenteuerlich. Die Zahlen sagen das wir
das genau nicht machen.

> Das weicht eben, wie gesagt, erst neuzeitlich auf, weil die Außenlinie
> der Fläche zusätzlich nochmal separat erfasst wird und die Bedeutung
> des linearen Objekts auch als Fläche /deshalb/ in den Hintergrund
> rückt.  Als reines Graphenobjekt wurde diese Mittellinie nie be-
> schrieben, sondern immer als die Repräsentation einer Fläche mit
> (relativ) konstanter Breite, Verwendung, Zustand und Klassifikation.

Aeh - Diese Erkenntnis entnimmst du genau welcher Tatsache? Ich kenne
OSM eigentlich genau anders herum. Wir haben nie Breiten erfasst sondern
immer nur Mittellinien. Ausschliesslich der Renderer hat "angenommene
Breiten" nach Typenklassen und Zoomlevel dazugeschummelt. Explizit
erfasst haben wir Breiten nie und die Renderer haben das auch nie
ausgewertet.

> Und nochmal:  Es ist nicht "falsch", wenn eine Grenzlinie einen Offset
> besitzt, sondern bestenfalls "ungenau".  Andernfalls stellst du das
> gesamte Projekt in Frage.  Es gibt unzählige Koordinaten in OSM, die
> ab irgend einer Kommastelle falsch sind.  Jede Messung kennt ihren
> Messfehler.  Selbst Galileo wird daran nichts ändern, aber viel-
> leicht verschieben sich diese Diskussionen sinnfreierweise dann
> tatsächlich in den qcm-Bereich, wer weiß..

Der Messfehler von Galileo hat absolut gar nichts mit dem Runden der
Position der Ecke eines Ackers auf die nächste Straße zu tun. Der wird
noch oben drauf gerechnet auf den absoluten Lagefehler.

Diesen Fehler den du Propagierst ist ein Vielfaches (30-50 Fach) der
Ortophoto Auflösung die uns in D zur Verfügung steht und auch ein
vielfaches der aktuellen GNSS möglichkeiten. Dazu kommt das der Fehler
sich ja summiert. D.h. ich runde die Ecke des Ackers auf die Mitte einer
Straße deren absolute Lage ja schon den Messfehlern der GNSS oder
Ortophotos unterliegt.

Du willst VORSÄTZLICH einen Fehler hinzufügen und hast
mehrfach behauptet den könne "man" ja herausrechnen - Eine Anwendung
oder Algorithmus der dieses schafft bist du schuldig geblieben.

Ich habe mehrfach das Gegenteil behauptet und dafür auch klare
Grundlagen genannt - Ich sehe einfach nicht den Vorteil für eine 
Minderheit (Nachweis siehe vorangegangene Mail) die kein "Nichts" in der
Karte sehen will, allen Flächen absichtlich Fehler
Geographischer und Topologischer Natur hinzuzufügen und es dazu für
Neumapper nahezu unmöglich zu machen korrekte Daten zu erfassen.

Man kann das eben genau nicht raus rechnen oder "Mal eben Algorithmisch
Lösen" - Diesen Beweis sind bisher alle die das behauptet haben schuldig
geblieben.

Wenn ich alle Beträge eines Kassensystems auf volle € runde kann ich
hinterher nicht mehr die Cent Beträge ausgeben.

Flo
-- 
Florian Lohoff f...@zz.de
 UTF-8 Test: The  ran after a , but the  ran away


signature.asc
Description: PGP signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Martin Koppenhoefer]

sent from a phone

> On 7. Apr 2018, at 23:51, Christian Müller  wrote:
> 
> Das man das auch als Linie
> in einem Routing-Graphen /verwenden/ kann, ist ein anderer Aspekt, aber
> sowohl das Datenmodell, als auch die width-Tags sprechen eine klare,
> andere Sprache:  Das Faktum ist die Wegfläche, ihre Kodierung die /ange-
> näherte/ Mittellinie.


width ist nur eine (dazuhin kaum erfasste) Eigenschaft der Linie, um die 
Fläche, die damit beschrieben werden soll, geht es im OSM Modell für highway 
aber praktisch nicht, was man z.B. daran sieht, dass man z.B. zwar Spuranzahlen 
erfasst, aber normalerweise nicht wie breit die Spuren sind oder wie sie am 
Anfang und Ende ineinander übergehen und wo und wielange diese Übergänge sind, 
oder wo quergestreifte Teilflächen sind, oder wo es breitere und engere Stellen 
gibt, wo Schlaglöcher liegen, etc (teilweise wurde das mit dem lanes-tagging 
nachträglich etwas verbessert). Nüchtern betrachtet gibt es (gab es lange) 
praktisch keine tags um die Fläche einer Straße oder eines Wegs zu beschreiben, 
weil alles auf eindimensionale Verbindungen ausgerichtet war.


Gruß,
Martin
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Christian Müller]

> Gesendet: Samstag, 07. April 2018 um 23:30 Uhr
> Von: "Florian Lohoff" <f...@zz.de>
> An: "Christian Müller" <cmu...@gmx.de>
> Cc: talk-de@openstreetmap.org
> Betreff: Re: [Talk-de] Flächen/Wege // Trolling in changesets
>
> > > Sobald du eine Fläche mit dem Weg verbindest behauptest du das diese
> > > Seite Geometrisch zu dem landuse daneben gehörst. Das sagst du dadurch
> > > das die neue Grenze des landuses die Knoten in der Straßenmitte sind.
> > 
> > Das ist nicht wahr, weil das eine Interpretationsfrage ist.  Ob die Knoten
> > in der Straßenmitte zur Fläche gehören, oder eine (zu berechnende Grenze),
> > die sich aus dem Versatz der Knoten in der Straßenmitte um die Hälfte der
> > getaggten Breite (oder einer Standardbreite, wenn wir einen Fehler durch
> > Abstraktion akzeptieren) ergibt, ist Frage der Gestaltung.
> 
> Nein - Wir behaupten das ein Knoten an der Absoluten Position 51.434
> 8.123 ist - Und nicht - An dieser Stelle -8m/2 rechtwinkelig zu einem
> der Wegen die diesen Knoten enthält. Das machen wir NIRGENDS bei OSM.
> 
> OSM ist eine Sammlung von Geografischen Fakten - Und das ist dann eben
> kein Faktum sondern evtl. eine Konstruktionshilfe.

Das ist nett gedacht, aber diese Argumentation funktioniert hinten und
vorne nicht, weil die Mittellinie /nicht als Faktum/, sondern selbst
als Konstruktionshilfe eingetragen wird.

Wir erfassen ja mit der Mittellinie eben /nicht/ die Mittellinie sondern
ein geographisches Objekt mit einer Breite.  Das man das auch als Linie
in einem Routing-Graphen /verwenden/ kann, ist ein anderer Aspekt, aber
sowohl das Datenmodell, als auch die width-Tags sprechen eine klare,
andere Sprache:  Das Faktum ist die Wegfläche, ihre Kodierung die /ange-
näherte/ Mittellinie.

Das weicht eben, wie gesagt, erst neuzeitlich auf, weil die Außenlinie
der Fläche zusätzlich nochmal separat erfasst wird und die Bedeutung
des linearen Objekts auch als Fläche /deshalb/ in den Hintergrund
rückt.  Als reines Graphenobjekt wurde diese Mittellinie nie be-
schrieben, sondern immer als die Repräsentation einer Fläche mit
(relativ) konstanter Breite, Verwendung, Zustand und Klassifikation.


Und nochmal:  Es ist nicht "falsch", wenn eine Grenzlinie einen Offset
besitzt, sondern bestenfalls "ungenau".  Andernfalls stellst du das
gesamte Projekt in Frage.  Es gibt unzählige Koordinaten in OSM, die
ab irgend einer Kommastelle falsch sind.  Jede Messung kennt ihren
Messfehler.  Selbst Galileo wird daran nichts ändern, aber viel-
leicht verschieben sich diese Diskussionen sinnfreierweise dann
tatsächlich in den qcm-Bereich, wer weiß..


Gruß

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Florian Lohoff]

Hola,

On Sat, Apr 07, 2018 at 09:06:09PM +0200, "Christian Müller" wrote:
> > Sent: Thu, 5 Apr 2018 16:38:49 +0200 
> > From: "Florian Lohoff" <f...@zz.de>
> > To: "Christian Müller" <cmu...@gmx.de>
> > Cc: talk-de@openstreetmap.org
> > Subject: Re: [Talk-de] Flächen/Wege // Trolling in changesets
> >
> > Sobald du eine Fläche mit dem Weg verbindest behauptest du das diese
> > Seite Geometrisch zu dem landuse daneben gehörst. Das sagst du dadurch
> > das die neue Grenze des landuses die Knoten in der Straßenmitte sind.
> 
> Das ist nicht wahr, weil das eine Interpretationsfrage ist.  Ob die Knoten
> in der Straßenmitte zur Fläche gehören, oder eine (zu berechnende Grenze),
> die sich aus dem Versatz der Knoten in der Straßenmitte um die Hälfte der
> getaggten Breite (oder einer Standardbreite, wenn wir einen Fehler durch
> Abstraktion akzeptieren) ergibt, ist Frage der Gestaltung.

Nein - Wir behaupten das ein Knoten an der Absoluten Position 51.434
8.123 ist - Und nicht - An dieser Stelle -8m/2 rechtwinkelig zu einem
der Wegen die diesen Knoten enthält. Das machen wir NIRGENDS bei OSM.

OSM ist eine Sammlung von Geografischen Fakten - Und das ist dann eben
kein Faktum sondern evtl. eine Konstruktionshilfe.

> Wir bearbeiten hier aber zum Teil Geschichte, weil sich die Mappenden bei
> OSM i.d.R. sehr stark am Luftbild orientieren (lies: es abzeichnen), als
> damit, welche alternativen Möglichkeiten es gibt, das Datenmodell wartungs-
> arm zu fortzuentwickeln.  Die detaillierten Luftbilder abzuzeichnen dürfte
> zu den intuitiveren Methoden zählen, aber auch zu den aufwendigsten.  Es
> ist keine sparsame, sondern eher eine gründliche Methode, die aber für
> abstraktere Datenmodelle evtl. eine -grundlage liefert.

s.o. Fakten - nicht Konstruktionshilfen.

> > Wir zeichnen eine Linie in der Mitte um einen routingfähigen Graphen zu
> > bekommen. Wenn du das geometrisch richtig machen willst musst du den Weg
> > auch zusätzlich als Fläche erfassen. Da gibt es ja reichlich versuche
> > zu.
> 
> Da stimme ich mit dir überein.  Die Gefahr die besteht ist, dass Mapper
> beginnen, Mittellinien (also die Wegabstraktion) zu entfernen, wo Wege
> als Flächen gemappt wurden.  Die Argumentation wird (korrekterweise)
> sein, dass es auch Routingalgorithmen gibt, die Flächen verarbeiten
> können.

Ich kenne nur versuche Routing über Flächen zu machen - Ich kenne niemanden
der sowas in Produktion oder Nutzbar hat. Mal ganz davon abgesehen das
es computational ein Desaster ist.

> Je mehr Mittellinien dann aus dem Bestand verschwinden, desto nutzloser
> wird es, sich diese für ein Nicht-Flächen-Routing herauszufiltern.  Bei
> vielen gepflasterten Plätzen habe ich das schon beobachtet - es werden
> keine ergänzenden highway=* Linien für Legacy-Router eingetragen.

Legacy = Alles was heute irgendwo in Benutzung ist. Als Hilfskonstrukt
Routen aktuell die Routingalgorithmen über die Aussenkante der Flächen. Was
halt kaputt ist.

> M.M.n. fährt OSM mit dem Hybrid-Modell eigentlich ganz gut (also beides
> einzutragen, obwohl es redundant ist).  Ich verstehe aber auch die Gegner,
> die häufig mit dem Argument der Redundanzvermeidung um sich werfen, aber
> keine Lösung haben, ob die Redundanz durch das Behalten der Fläche, oder
> das Behalten der abstrakteren Mittellinie aufzulösen sei.  Der maximal-
> kooperative Ansatz ist also, beide Varianten zu behalten, imho.

Graphen und Flächen sind eben keine Redundanten Informationen. Das sieht
man schon an der Verklebediskussion. Ein Graph/Mittellinie KANN und WIRD
niemals die Fläche ersetzen können.

> > Verkleben bedeutet Abstraktion und Informationsverlust - Genauer
> > eigentlich sogar nicht Verlust sondern Verfälschung. Die Begrenzung
> > der Fläche sind absichtlich falsch um eine Lücke zwischen Straße und
> > Fläche zu vermeiden. Ein anderes Argument kenne ich nicht.
> 
> Das ist sehr total, aber für viele Anwendungen ist diese Totale völlig
> irrelevant, weil der Detailgrad, den du anstrebst für viele Anwendungen
> nicht relevant ist (tatsächlich ist er eigentlich nur für eine genaue
> Flächenberechnung relevant).  Für topologische Aussagen, etwa "neben
> der Straße liegt das Feld, es zählt zu folgender Größen/ordnung/" ist
> das nicht wichtig.  Und wenn es einen Standard gibt, dass z.B. jede
> Straße einen Straßengraben bestimmter Breite haben muss, dann ist der
> Fehler, den du wegen des Informationsverlustes bei der Berechnung mit
> Standardwerten erleidest, eben nicht die Regel, sondern eine vernach-
> lässigbare Ausnahme.

s.o. OSM ist eine Sammlung von Fakten. Das was du vorschlägst ist
absichtlich inkorrekte Fakten einzutragen.

> Aber wie gesagt, die meisten Leute sind, was OSM betrifft, nicht an
>

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Christian Müller]

> Sent: Thu, 5 Apr 2018 16:19:29 +0200 
> From: "Florian Lohoff" <f...@zz.de>
> To: "Christian Müller" <cmu...@gmx.de>
> Cc: talk-de@openstreetmap.org
> Subject: Re: [Talk-de] Flächen/Wege // Trolling in changesets
>
> Relations sind schön - aber wenn massenhaft verwendet einfach nicht
> handhabbar.

Oft zitiert, nie erreicht:  Es war ja mal angedacht, einen Flächen-
typ in die API zu integrieren.  Vielleicht ist es dazu (im Rahmen
von OSM) wirklich zu spät, aber damit könnten serverseitig viele
Changesets abgelehnt werden, die zu den kaputten Daten führen, denen
du mit dem Werkzeugkoffer hinterherrennen sollst.

Serverseitig wird wenig validiert, obwohl vielmehr validiert werden
könnte.  Hier stehen Freiheit und Offenheit vor Sicherheit.

MPs und die boundary Relationen sind ein Ersatz für diesen Flächen-
typ.  Sie gehen deshalb oft kaputt, weil sie serverseitig von anderen
Relationen nicht unterschieden werden und beim Upload keine Valid.
stattfindet.

D.h. falls du mit der Kommunikation und dem Versenden von Doku
nicht glücklich wirst, weil es auf der Gegenseite scheinbar unbe-
arbeitet liegen bleibt, dann wäre die Anpassung auf der Server-
seite eine Option und falls dort niemand reagiert, etwas Neues
aufzusetzen.  Die history-Interessierten haben das m.W. schon-
mal gemacht:

https://wiki.openstreetmap.org/wiki/Open_Historical_Map#Short-term_plans


Ich weigere mich aber zu glauben, dass das wirklich die Masse
sein soll, die dir ihre Arbeit überhilft.


Gruß

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Christian Müller]

> Sent: Sat, 7 Apr 2018 20:47:30 +0200 
> From: Markus <liste12a4...@gmx.de>
> To: talk-de@openstreetmap.org
> Subject: Re: [Talk-de] Flächen/Wege // Trolling in changesets
>
> Hallo Christian,
> 
> hier geht es um das "Verkleben", das vielerorts viel Mühe und Ärger
> macht. Und eben darum, dafür zu werben, dass man nicht nur um etwas
> "schön" zu machen, Objekte verklebt, die dann andere mühsam wieder
> auseinaderdröseln müssen :-)

Hallo Markus,


sicher wird dir nicht entgangen sein, dass es nicht nur einen Weg gibt,
die Daten in OSM zu bearbeiten.  Es ist also auch gewagt und subjektiv,
zu meinen, dass die Entkleber nun mehr Mühe und Ärger mit den Verklebern
hätten, als umgekehrt.

Wenn man sich mal auf deinen Standpunkt bezieht, dass alles relativ ist,
dann ist auch das Entkleben relativ "falsch".


> Wenn man es - neben der vielfach beschriebenen Mühsal - unbedingt noch
> anderweitig "erklären" muss, dann könnte man es so tun:
> 
> Wir kartografieren die Erde. Dafür haben wir ein Modell (Geoid), dessen
> Oberfläche ursprünglich leer (weiss) war. Darauf haben wir begonnen, uns
> bekannte Objekte abzubilden. Strassen (als Linien), Orte früher als
> Punkte, später als ungefähre Flächen, heute als Menge von
> Gebäudeflächen), Gewässer (Linen für Flüsse, Flächen für Seen), Wälder
> (als ungefähre Flächen), Berge (deren Gipfel als Punkt) etc., etc.
> Und "dazwischen" - also da wo noch niemand etwas eingetragen hatte, da
> war einfach ein "weisser Fleck".

Was hat das denn nun mit dem Ver- und Entkleben zu tun?

Mal abgesehen davon, dass du die iterative Arbeitsweise des Kartierens als
Problem empfindest (Temporale Geschichte, wenn ein großer Forst /ursprünglich/
mal kleinere Siedlungen wegabstrahiert hat und die Details erst nach und
nach ergänzt wurden), habe ich für meinen Teil seltenst Monsterflächen an-
gelegt.  Aber an "unbearbeiteten" Leerraum, der also auch noch nicht durch
eine grobe Abstraktion beschrieben war, kann ich mich noch ganz gut erinnern,
wobei ich nicht behaupten würde, dass das nun besser oder einfacher war, als
mit dem derzeitigen Bestand zu arbeiten.

Deine Argumentation basiert im großen Teil darauf, dass es eine Last wäre,
Bestandsdaten zu editieren, wenn um die Neudaten herum, schon Bestand ex-
istiert, der miteditiert werden muss.  Niemand zwingt Mappende, bei OSM
mitzumachen, wenn dir das Editieren /deshalb/ keinen Spaß mehr macht,
weil du keine /leere/ Fläche mehr vorfindest, starte doch einfach einen
neuen Server, und fange von vorn an.  Ich für meinen Teil, editiere auch
Bestandsdaten gern - ob dabei etwas zu Entkleben ist, oder nicht, ist
dabei eigentlich unerheblich.

Du hängst dich zwar an dem "Verklebt-Sein" zwischen linearen und arealen
Objekten auf, aber die Implikation ist viel weitreichender:  Die Grenzen
von Ländern und Bundesländern waren recht zeitig gemappt (ohne "unschöne"
Lücken an den Landesgrenzen - weiß nicht, ob du auch dort Lücken lassen
würdest).  Diese Grenzen aber bilden Flächen.  Der Leerraum oder der
"weiße Fleck" den du also auf hoher Zoomstufe identifiziert haben wolltest,
war zu diesem Zeitpunkt schon längst von einer Fläche überstrichen, zu
dem Du in diese Fläche eine weitere eingezeichnet hattest.  Quizfrage:

War es ein Problem, dass diese Flächen und Flächengrenzen der Länder
existierten?  War es problematisch, dass die "verklebt" waren (womit
auch immer, ob mit Flußläufen, Flussmitten, o.ä.?)?  War es für deine
Edits irgendwie von Belang?  Ich schätze nicht..

Sofern du nicht eine Enklave oder Exklave gemappt hast, musstest du
diese Bestandsdaten auch nicht anpassen?  D.h. wenn umgebende Flächen
topologisch sinnvoll gemappt sind, dann müssen ihre Datenschnipsel in
der DB überhaupt nicht berührt werden, wenn Neudaten ergänzt werden?

Die "Last" Flächen neu zu mappen oder umzumappen entsteht regelmäßig
u.a. dann, wenn ein Paradigmenwechsel durch Wiki oder Mailingliste
fegt, und dazu führt, dass Daten, die früher unter einem anderen
Paradigma eingetragen wurden, plötzlich ihre Gültigkeit verlieren
(beispielhaft weil Teiche in einem Forst nicht mehr Teil der Forst-
fläche sein sollen und als 'inner' von umliegenden Waldflächen aus-
genommen werden, etc. pp.).  


> Das ist was Martin meint mit:
> 
> >> im „Nichts“ kleine Dinge ablegen. 
> 
> Und plötzlich tauchten die "Hübschmacher" auf.
> Die "klebten" einfach alles aneinander, dann waren die weissen Flecken
> verschwunden.
> Und wir hatten in einigen Regionen besonders "hübsche" Karten ;-)
> 
> Gleichzeitig war es aber halt nun schwierig, die "hübschen Karten" zu
> verbessern. :-(

Ich stimme hier mit dir überein, ich sehe es auch ungern, wenn ungeduldige
Mapper gigantische Flächen mit einem einzigen Tag beschreiben, nur damit
d

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Christian Müller]

> Sent: Thu, 5 Apr 2018 16:38:49 +0200 
> From: "Florian Lohoff" <f...@zz.de>
> To: "Christian Müller" <cmu...@gmx.de>
> Cc: talk-de@openstreetmap.org
> Subject: Re: [Talk-de] Flächen/Wege // Trolling in changesets
>
> Sobald du eine Fläche mit dem Weg verbindest behauptest du das diese
> Seite Geometrisch zu dem landuse daneben gehörst. Das sagst du dadurch
> das die neue Grenze des landuses die Knoten in der Straßenmitte sind.

Das ist nicht wahr, weil das eine Interpretationsfrage ist.  Ob die Knoten
in der Straßenmitte zur Fläche gehören, oder eine (zu berechnende Grenze),
die sich aus dem Versatz der Knoten in der Straßenmitte um die Hälfte der
getaggten Breite (oder einer Standardbreite, wenn wir einen Fehler durch
Abstraktion akzeptieren) ergibt, ist Frage der Gestaltung.

Wir bearbeiten hier aber zum Teil Geschichte, weil sich die Mappenden bei
OSM i.d.R. sehr stark am Luftbild orientieren (lies: es abzeichnen), als
damit, welche alternativen Möglichkeiten es gibt, das Datenmodell wartungs-
arm zu fortzuentwickeln.  Die detaillierten Luftbilder abzuzeichnen dürfte
zu den intuitiveren Methoden zählen, aber auch zu den aufwendigsten.  Es
ist keine sparsame, sondern eher eine gründliche Methode, die aber für
abstraktere Datenmodelle evtl. eine -grundlage liefert.


> Das sehe ich als Fehler. Der Weg an der "Waldgrenze" gehört ja nicht zum
> Wald und auch nicht zum Acker daneben. Er ist eigenständig.

Ja, das ist (d)eine Sichtweise, aber der nächste kommt und sagt, der Weg /ist/
die Waldgrenze und dann gehört er sowohl zum Acker als auch zum Wald.  Er
ist Bindeglied (oder Trennglied) und kann als solches eigenständig betrachtet
werden, oder eben nicht.  Diese Sichtweise(n) wird(werden) ja gerade dann
modelliert, wenn der Weg (die Weglinie in den Daten) als Grenze wiederver-
wendet wird.


> Wir zeichnen eine Linie in der Mitte um einen routingfähigen Graphen zu
> bekommen. Wenn du das geometrisch richtig machen willst musst du den Weg
> auch zusätzlich als Fläche erfassen. Da gibt es ja reichlich versuche
> zu.

Da stimme ich mit dir überein.  Die Gefahr die besteht ist, dass Mapper
beginnen, Mittellinien (also die Wegabstraktion) zu entfernen, wo Wege
als Flächen gemappt wurden.  Die Argumentation wird (korrekterweise)
sein, dass es auch Routingalgorithmen gibt, die Flächen verarbeiten
können.

Je mehr Mittellinien dann aus dem Bestand verschwinden, desto nutzloser
wird es, sich diese für ein Nicht-Flächen-Routing herauszufiltern.  Bei
vielen gepflasterten Plätzen habe ich das schon beobachtet - es werden
keine ergänzenden highway=* Linien für Legacy-Router eingetragen.

M.M.n. fährt OSM mit dem Hybrid-Modell eigentlich ganz gut (also beides
einzutragen, obwohl es redundant ist).  Ich verstehe aber auch die Gegner,
die häufig mit dem Argument der Redundanzvermeidung um sich werfen, aber
keine Lösung haben, ob die Redundanz durch das Behalten der Fläche, oder
das Behalten der abstrakteren Mittellinie aufzulösen sei.  Der maximal-
kooperative Ansatz ist also, beide Varianten zu behalten, imho.


> Verkleben bedeutet Abstraktion und Informationsverlust - Genauer
> eigentlich sogar nicht Verlust sondern Verfälschung. Die Begrenzung
> der Fläche sind absichtlich falsch um eine Lücke zwischen Straße und
> Fläche zu vermeiden. Ein anderes Argument kenne ich nicht.

Das ist sehr total, aber für viele Anwendungen ist diese Totale völlig
irrelevant, weil der Detailgrad, den du anstrebst für viele Anwendungen
nicht relevant ist (tatsächlich ist er eigentlich nur für eine genaue
Flächenberechnung relevant).  Für topologische Aussagen, etwa "neben
der Straße liegt das Feld, es zählt zu folgender Größen/ordnung/" ist
das nicht wichtig.  Und wenn es einen Standard gibt, dass z.B. jede
Straße einen Straßengraben bestimmter Breite haben muss, dann ist der
Fehler, den du wegen des Informationsverlustes bei der Berechnung mit
Standardwerten erleidest, eben nicht die Regel, sondern eine vernach-
lässigbare Ausnahme.

Aber wie gesagt, die meisten Leute sind, was OSM betrifft, nicht an
einer abstrakten, topologisch richtigen Karte interessiert, sondern
an einer, die möglichst nahe an die Vogelperspektive herankommt, so
dass auch die hohen Zoomstufen nicht Nichts enthalten.

> > Wie bereits gesagt, entsteht dadurch ein Fehler (abstraktions-
> > bedingt), der bei der Flächenberechnung aber z.B. dadurch min-
> > imiert werden kann, dass (Länge*getaggte Breite)/2 von der Be-
> > rechnung der Flächengröße der geklebten Fläche abgezogen werden
> > kann.  /Wenn/ alle Flächen so gemappt würden, dann ist das auch
> > programmatisch einfachst umzusetzen, dann programmiert man das
> > einmal und gut ist.
> 
> "man" oder "Du" - Ich kenne derzeit keine Anwendung die das macht. Wir
> haben seit 10 Jahren das Thema das Straßen und Flußbreiten nichtmal
> 

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Markus]

Hallo Christian,

hier geht es um das "Verkleben", das vielerorts viel Mühe und Ärger
macht. Und eben darum, dafür zu werben, dass man nicht nur um etwas
"schön" zu machen, Objekte verklebt, die dann andere mühsam wieder
auseinaderdröseln müssen :-)

Wenn man es - neben der vielfach beschriebenen Mühsal - unbedingt noch
anderweitig "erklären" muss, dann könnte man es so tun:

Wir kartografieren die Erde. Dafür haben wir ein Modell (Geoid), dessen
Oberfläche ursprünglich leer (weiss) war. Darauf haben wir begonnen, uns
bekannte Objekte abzubilden. Strassen (als Linien), Orte früher als
Punkte, später als ungefähre Flächen, heute als Menge von
Gebäudeflächen), Gewässer (Linen für Flüsse, Flächen für Seen), Wälder
(als ungefähre Flächen), Berge (deren Gipfel als Punkt) etc., etc.
Und "dazwischen" - also da wo noch niemand etwas eingetragen hatte, da
war einfach ein "weisser Fleck".

Das ist was Martin meint mit:

>> im „Nichts“ kleine Dinge ablegen. 

Und plötzlich tauchten die "Hübschmacher" auf.
Die "klebten" einfach alles aneinander, dann waren die weissen Flecken
verschwunden.
Und wir hatten in einigen Regionen besonders "hübsche" Karten ;-)

Gleichzeitig war es aber halt nun schwierig, die "hübschen Karten" zu
verbessern. :-(

Womit wir wieder beim Anliegen dieses Threads wären...

Deshalb mein Wunsch:
Wenn Du eine Fläche kennst: male sie in die Karte. Wenn Du sie genau
kennst, male sie genau, wenn nicht dann halt so gut wie möglich.
Aber bitte: male Deine Punkte bitte so, dass sie nicht auf andere Punkte
oder Linien "springen"!
Mit JOSM kannst Du das verhindern, indem Du beim Punkte-Setzen die
Steuerungs-Taste festhältst. Und wenn es trotzdem mal passiert: einfach
mit Steuerung-R wieder einen Schritt zurück :-)

> Ignoranz dem Faktischen gegenüber.

Das finde ich etwas gewagt...
Wenig wertschätzend für die Arbeit Anderer.

Denn das mit der "Wirklichkeit" - die bleibt hat relativ.

Und solange wir uns weder einig sind, wann ein Objekt wie von einem
anderen zu unterscheiden ist, und solange wir nicht in der Lage sind, im
Wiki die Unterschiede die "wir" (wer?) meinen, bildhaft eindeutig
nachvollziehbar zu unterscheiden,
solange macht es m.E. Sinn, die "Lücken" explizit frei zu lassen,
damit sie durch Verfeinerung, Ergänzung, Korrektur unkompliziert
bearbeitet werden können :-)

Mit herzlichem Gruss,
Markus

PS: und ja, mit Deinen 3-dimensionalen Beispielen (Stadtbibliothek) hast
Du natürlich recht: solches in einer 2-dimensionalen Struktur abzubilden
zu wollen führt unweigerlich zu Problemen.
Genauso wie wenn man unscharfe Elemente (Harz) in eine Fläche zu pressen
versucht, oder auf einen Punkt reduziert.
Da braucht man ziemlich stabile Regeln, damit solches nicht ins Chaos führt.
(aber das wäre ein anderer Thread...)


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Christian Müller]

> Sent: Donnerstag, 05. April 2018 um 22:04 Uhr
> From: "Martin Koppenhoefer" <dieterdre...@gmail.com>
> To: "Openstreetmap allgemeines in Deutsch" <talk-de@openstreetmap.org>
> Cc: "Christian Müller" <cmu...@gmx.de>
> Subject: Re: [Talk-de] Flächen/Wege // Trolling in changesets
> 
> On 5. Apr 2018, at 16:38, Florian Lohoff <f...@zz.de[mailto:f...@zz.de]> 
> wrote:
> 
> Es gibt keine Notwendigkeit das jeder quadratcentimeter zu einem landuse
> gehören muss. 
 
> +1, es wurde das Konzept vorgestellt eine „allumfassende Initial-Fläche“ 
> (kein Zitat) zu teilen[1] und weiterzuteilen usw., ich sehe OSM eher so, dass 
> man im „Nichts“ kleine Dinge ablegt. Punkte oder kleine Gebiete, die man dann 
> gemeinsam beschreibt und anpasst. Diese „Dinge“ können sich da durchaus 
> überlappen. Aus dem Verhältnis der Dinge zueinander ergibt sich nach und nach 
> die Karte.


-1, sorry, aber im Nichts lassen sich keine kleinen Dinge ablegen.  Und diese 
allumfassende Initial-Fläche, mit ihren Höhen und Tiefen ist kein Konzept, 
sondern beobachtbare Realität.  Gebiete ohne ihre Nachbargebiete zu betrachten, 
ist eine Krücke für den Anfang von Kartenprojekten - es gibt keine 
Notwendigkeit sich daran festzuklammern.  Das kann man tun, zeugt aber eher von 
einer Ignoranz dem Faktischen gegenüber.

Richtig ist, dass nicht jede Fläche mit landuse=* keys beschreibbar ist, da es 
auch Flächen gibt, die nicht genutzt werden (das sind aber gerade in 
Ballungsräumen sehr wenige)  und  die Frage 'Was gehört zur Landnutzung?' ist 
zudem nicht abschließend erörtert.  Grundsätzlich aber wird bei OSM eine große 
Fläche ihren Funktionen oder Eigenschaften nach unterteilt - und es ist nicht 
unbedingt so, dass Iterationen dieser Unterteilungen dazu führen, dass größere 
Regionen verschwinden würden.  Das Prinzip der Unterteilung folgt eher dem der 
https://de.wikipedia.org/wiki/Matrjoschka - das war ja auch schon am Beispiel 
von 'Berliner Stadtbibliothek' und einem mgl. Indoor-Mapping, oder der 
naturräumlichen Region des 'Harz' in einer früheren Mail zum Thema ableitbar.  

Zählt ein Gebiet, dass vom Menschen deklarativ als Naturwald bezeichnet wurde 
(und aus dem er sich erklärterweise entfernt hat) dazu, oder eher nicht?  Das 
ist sprachlich nicht einfach zu lösen, denn immerhin besteht ja zumindest ein 
passiver Nutzen für den Menschen, selbst dann wenn das Gebiet nicht zur 
Naherholung verwendet wird, produziert es Ressourcen, die vom Menschen 
'genutzt' werden.


Gruß
cmuelle8

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Martin Koppenhoefer]

sent from a phone

> On 5. Apr 2018, at 16:38, Florian Lohoff  wrote:
> 
> Es gibt keine Notwendigkeit das jeder quadratcentimeter zu einem landuse
> gehören muss.


+1, es wurde das Konzept vorgestellt eine „allumfassende Initial-Fläche“ (kein 
Zitat) zu teilen[1] und weiterzuteilen usw., ich sehe OSM eher so, dass man im 
„Nichts“ kleine Dinge ablegt. Punkte oder kleine Gebiete, die man dann 
gemeinsam beschreibt und anpasst. Diese „Dinge“ können sich da durchaus 
überlappen. Aus dem Verhältnis der Dinge zueinander ergibt sich nach und nach 
die Karte.


Gruß,
Martin 


[1] https://lists.openstreetmap.org/pipermail/talk-de/2018-April/114803.html
„Es steht eine Gesamtfläche zum Mappen zur Verfügung und die Frage ist, wie 
genau und wo man sie unterteilt, um Teilflächen zu beschreiben.“
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Rainer]

 <f...@zz.de>
To: "Christian Müller" <cmu...@gmx.de>
Cc: talk-de@openstreetmap.org
Subject: Re: [Talk-de] Flächen/Wege // Trolling in changesets

Ich hatte ja in dem Thread auch ausgeführt das es ein Problem gibt mit
neumappern. Das Thema MP Relation und die Wege alle einzeln hinzufügen
ist noch eine viel größeres Pflegedesaster. Ich gebe dir Recht das das
eine total saubere Sache ist (Syntaktisch) - Aber leider ist das eben
für "gelegenheitsmapper" völlig ungeeignet.

Und wieder und wieder werden Leute bevormundet, die du überhaupt nicht
kennst, nie in deinem Leben gesehen hast, mit Behauptungen, die einzig
und allein einem Bauchgefühl (und vielleicht ein paar Beobachtungen in
den Daten) entspringen zu scheinen.

Der "Gelegenheitsmapper", das ist so der "Ottonormalverbraucher" oder
der "Kleine Mann", jeder will ihn kennen, nie hat ihn jemand gesehen
oder verstanden.

Wieviel Projekte wird das Internet noch sehen müssen, bevor sich der
letzte von solchen Aussagen trennt?

Du unterschlägst sowohl Intelligenz, Wissbegier, Neugier, Lernfähigkeit
der freiwilligen Mapper, imho.  Vielleicht liegt dein Fokus auch zu sehr
auf den vermeintlichen Problemen, anstatt zu sehen, dass eine ganze
Menge an Edits eben nicht fehlerbehaftet ist.


Gruß
cmuelle8

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de



___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Florian Lohoff]

On Wed, Apr 04, 2018 at 06:23:57PM +0200, "Christian Müller" wrote:
> Vielleicht läuft auf der Waldgrenze ein Weg, der hat, bei genauer
> Betrachtung eine Fläche, also grenzt dann nicht Wald an Wiese,
> sondern Wald an Weg und Weg an Wiese, nicht?

Sobald du eine Fläche mit dem Weg verbindest behauptest du das diese
Seite Geometrisch zu dem landuse daneben gehörst. Das sagst du dadurch
das die neue Grenze des landuses die Knoten in der Straßenmitte sind.

Das sehe ich als Fehler. Der Weg an der "Waldgrenze" gehört ja nicht zum
Wald und auch nicht zum Acker daneben. Er ist eigenständig.

Wir zeichnen eine Linie in der Mitte um einen routingfähigen Graphen zu
bekommen. Wenn du das geometrisch richtig machen willst musst du den Weg
auch zusätzlich als Fläche erfassen. Da gibt es ja reichlich versuche
zu.

> Nochmal, das Problem ist eines der Abwägung:  Wieviel Detail soll
> erfasst werden und wieviel Detail darf durch Abstraktion verloren
> gehen!?

Verkleben bedeutet Abstraktion und Informationsverlust - Genauer
eigentlich sogar nicht Verlust sondern Verfälschung. Die Begrenzung
der Fläche sind absichtlich falsch um eine Lücke zwischen Straße und
Fläche zu vermeiden. Ein anderes Argument kenne ich nicht.

> Wie bereits gesagt, entsteht dadurch ein Fehler (abstraktions-
> bedingt), der bei der Flächenberechnung aber z.B. dadurch min-
> imiert werden kann, dass (Länge*getaggte Breite)/2 von der Be-
> rechnung der Flächengröße der geklebten Fläche abgezogen werden
> kann.  /Wenn/ alle Flächen so gemappt würden, dann ist das auch
> programmatisch einfachst umzusetzen, dann programmiert man das
> einmal und gut ist.

"man" oder "Du" - Ich kenne derzeit keine Anwendung die das macht. Wir
haben seit 10 Jahren das Thema das Straßen und Flußbreiten nichtmal
gerendert werden. Wenn das alles so einfach ist warum hat es dann noch
keiner gemacht?

> Je nachdem wie genau man hinschaut, lassen sich also mehr und
> mehr Flächen (und damit auch Flächengrenzen) identifizieren,
> aber es ist Unsinn, eine Lücke herzustellen, ohne diese dann
> auch als getaggte Fläche auszuzeichnen.

Warum? Die Böschung des Grabens - Stand heute machen die leute das zum
farmland. Defakto gehört das zum Graben. Jetzt kann man da natürlich
eine Riverbank einzeichnen für einen 30cm breiten graben. Das wiederum
halte ich für Mumpitz. Defakto ist da aber was was nicht zum farmland
gehört.

Es gibt keine Notwendigkeit das jeder quadratcentimeter zu einem landuse
gehören muss. Das ist mapping für den Renderer.

> Und auch das Phänomen, dass eine Fläche an eine andere an-
> schließt, wird sich durch Lückenbildung (egal aus welcher

Wir sind aber nicht beim verkleben von Flächen untereinander
sondern von Flächen mit Wegen.

> Ich bin Vereinfachungen gegenüber grundsätzlich aufgeschlossen,
> wenn sie keine Verschlimmbesserungen darstellen.

Dann lassen wir das mit dem verkleben. Das ist eine Vereinfachung 
die die Geometrie falsch abbildet.

> Die Kompliziertheit in OSM besteht nicht darin, dass MPs schwierig
> zu verstehen wären, sondern darin, dass sie eines von drei Mitteln
> der Flächendarstellung sind, alle drei bunt durchwürfelt zu finden
> sind, sie aber modellhaft und asymbiotisch konkurrieren.
> 
> Anders gesagt:  Es ist weniger bedeutsam, welche Methode Flächen ab-
> zubilden, genutzt wird.  Es sind alle einfach, sofern sie alleinig
> /einheitlich genutzt würden.  Wie Frederik bereits betonte, macht
> es aber keinen Sinn, dass mit Gewalt durchdrücken zu wollen.  Das
> muss sich evolutionär lösen.

Es ist wichtig eine gewisse Disziplin anzuwenden. Nicht alles weil
es einfach ist mal eben übereinanderklatschen und auch nicht drauf
achten ob dinge verbunden sind oder nicht.

Flo
-- 
Florian Lohoff f...@zz.de
 UTF-8 Test: The  ran after a , but the  ran away


signature.asc
Description: PGP signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Florian Lohoff]

On Wed, Apr 04, 2018 at 06:38:17PM +0200, "Christian Müller" wrote:
> Und wieder und wieder werden Leute bevormundet, die du überhaupt nicht
> kennst, nie in deinem Leben gesehen hast, mit Behauptungen, die einzig
> und allein einem Bauchgefühl (und vielleicht ein paar Beobachtungen in
> den Daten) entspringen zu scheinen.
> 
> Der "Gelegenheitsmapper", das ist so der "Ottonormalverbraucher" oder
> der "Kleine Mann", jeder will ihn kennen, nie hat ihn jemand gesehen
> oder verstanden.

> Wieviel Projekte wird das Internet noch sehen müssen, bevor sich der
> letzte von solchen Aussagen trennt?
> 
> Du unterschlägst sowohl Intelligenz, Wissbegier, Neugier, Lernfähigkeit
> der freiwilligen Mapper, imho.  Vielleicht liegt dein Fokus auch zu sehr
> auf den vermeintlichen Problemen, anstatt zu sehen, dass eine ganze
> Menge an Edits eben nicht fehlerbehaftet ist.

Das ist meine Erfahrung aus 10 Jahren. Ich kommentiere viel und
ausführlich in Changesets und meine Erfahrung ist das der neu und/oder
Gelegenheitsmapper schon mit viel einfacheren Dingen total überfordert
ist. Ich habe da keine "Top 10" aber so dinge wie "Es macht sinn die
Adresse auf dem Gebäudeoutline zu hinterlegen und nicht auf einem Node"
ist oft schon zu viel. Da bekomme ich dann zurück "Kannst du das nicht
reparieren - ich weiss nicht wie". Alternativ auch - "Wenn du ein
landuse in einem landuse machst du musst das mit einem Multipolygon
ausschneiden" - Die wissen oft nichtmal wovon ich rede und ich werde oft
gebeten das "mal eben" zu reparieren.

Und das ist für mich die Realität von OSM. Das Thema ist schon heute mit
den ganzen "Impliziten" Regeln und der dahinterstehenden Technik so
unglaublich kompliziert.

Und da geht es nicht darum das ICH anderen unterstelle nicht genug
Intelligenz mitzubrinen sondern das ist das was ich geschrieben bekomme
was sie nicht hinbekommen. Selbst wenn ich dann Doku mitschicke ist das
vielen zu kompliziert. Also repariere ich dann.

Relations sind schön - aber wenn massenhaft verwendet einfach nicht
handhabbar.

Flo
-- 
Florian Lohoff f...@zz.de
 UTF-8 Test: The  ran after a , but the  ran away


signature.asc
Description: PGP signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Florian Lohoff]

Hi Michael,

On Wed, Apr 04, 2018 at 07:54:30PM +0200, Michael Reichert wrote:
> Hallo Flo,

> An dem Quellcode wäre ich interessiert, um es mal bundesweit laufen zu
> lassen. Ich habe im Sommer 2015 eine Abstimmung auf Haralds
> Umfrageplattform gemacht, bei der die Nichtkleber in der Mehrheit waren.
> [1, 2, 3, 4]
> 
> Ich bin sehr daran interessiert, die Abstimmung mit den Füßen
> auszuwerten, und würde mich freuen, wenn du deinen Code entweder mir zur
> Verfügung stellen könntest oder gleich als freie Software
> veröffentlichen könntest. Die Auswertung ist nicht ganz einfach, weil
> man weder einfach die Objekte noch die Länge noch den Flächeninhalt
> zählen muss, sondern auch beachten muss, wer was beigetragen hat.

Kein ding:

git clone git://pax.zz.de/wayareaconflicts2

Braucht libosmium - geht davon aus das das im selben Verzeichniss liegt,
cmake und so ein bischen boost zeugs. Wobei ich glaube das gar nicht
mehr wirklich gebraucht wird.

Der möchte gerne ein pbf auf der command line und schreibt
dann im aktuellen Verzeichniss eine sqlite und den stdout
kannst du mit dem output-to-html in eine html Seite verwandeln.

Für NRW brauchst du ~12GByte Ram - Das dingen ist null optimiert und
eher so zusammengepfriemelt. Ich mache im moment Ostwestfalen-Lippe.

Was ich mache ist das ich mir für jeden node merke welche Wege attached
sind. Dann gehe ich alle Wege durch (Nur die lines - also high und
waterway) und gucke ob an 2 aufeinanderfolgenden nodes jeweils eine
area mit derselben ID attached ist.

Also ein Geometrischer match sondern ein logischer über die nodeIDs 

Es gibt ein paar cornercases die ich nicht abgeklopft habe.
Multipolygone sind das eine. Das andere sind wenn der erste und letzte
node verklebt sind (Des Weges oder der area) - Es könnte sein
das das dann unter Umständen nicht matched. War mir aber erstmal
nicht so wichtig. Erstmal die 80% Lösung und damit anfangen.

In der sqlite stehen für jeden weg/area jeweils die id, der letzte
bearbeiter, das letzte changeset und die letzte uhrzeit und eben
die geometrie einer linie zwischen den beiden nodes die überlappen.

Am ende hab ich mir überlegt noch alle nodes rauszuschreiben die 
jeweils an linien und Flächen sind. So das du auch einzelne
nodes findest. Ist so ein Sekundärproblem aber wenn man es eh
auswertet - Und falsch ist das in 90% der Fälle auch.

Flo
-- 
Florian Lohoff f...@zz.de
 UTF-8 Test: The  ran after a , but the  ran away


signature.asc
Description: PGP signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Volker Schmidt]

Ich habe mit Interesse diese Diskussion mitgelesen.
Was ich vermisse in diesen Ausfuehrungen, ist ein Hinweis, dass der
Konflikt vorprogrammiert ist durch die Tatsache, das das Daten-Modell von
OSM ein Hybrid ist. Es koexistieren zwei Datenmodelle:
1) ways mit implizit oder explizit angehefteten Breiten
2) Flaechen (Polygone)
Mit ways mit angehefteten Breiten kann man keine komplizierten Flaechen
beschreiben, mit Flaechen (shapes) kann man alles beschreiben, aber der
Preis dafuer ist ein groeserer Aufwand, der fuer viele Anwendungsfaellee
nicht notwendig ist.

Wenn man akzeptiert, dass in OSM beide Modelle koexistieren sollen, dann
kann man sich den praktischen Aspekten widmen. Und das ist haeufig ein
Kompromiss oder besser ein Provisorium.

Ich bin auch ein - gelegentlicher - Entkleber, aber nicht aus Prinzip,
sondern einfach weil ich mit der Verbesserung der Daten, die ich verbessern
kann, vorankommen will. Genauer: ich moechte die Verwendbarkeit von OSM
fuer Radfahrer verbessern, weil ich sie selbst benutze. Ich kann nicht
ausserdem alle "Fehler" beseitigen, die links und rechts "meiner"
Radstrecke liegen. Normalerweise benutze ich meine eigenen GPX tracks und,
zumindest seit den letzten zwei Jahren, in der Regel auch Mapillary-Fotos.
Ein typischer Fall:
Ich treffe auf einen an die Strasse angeklebten, mehrere Hektar grossen
landuse=farmland, vor acht Jahren importiert, und wahrscheinlich vom Inhalt
her deutlich aelter, und beim Import nicht kontrolliert. Mittlerweile steht
dort ein Supermarkt und eine Neubausiedlung. Die Strasse ist von einem
freundlichen OSM-Kollegen recht grob eingetragen worden, mit erhebliche
Geometrie-Fehlern. Ausserdem sehe ich auf den Fotos, dass neben der Strasse
ein Drainage-Graben ist, der auf der Karte fehlt, und der jetzt teilweise
unterirdisch verlaeuft, und jenseits davon ein neuer Fuss-Rad-Weg.
Was mach ich da? Als erstes wird der landuse entklebt, da er offensichtlich
nicht den Tasachen entspricht und ein fixme draufgesetzt. Die
Strassen-Geometrie verbessere ich soweit moeglich, Den neuen Radweg, den
Graben, wo er sichtbar ist, und die neuen Strassen trage ich ein (falls sie
schon auf den Satellitenbildern drauf sind, sonst nur die Einmuendungen von
den Mapllary Fotos). Landuse und neue Gebauede lasse ich fuer andere.
Ausser dem Supermarkt, falls ich auf den Fotos den Namen sehe. Den setze
ich mit ungefaehrer Position ein. Aber der offensichtlich falsche landuse
bleibt - mit fixme - auf der Karte, mit seiner falschen Geometrie und tags,
aber er ist nicht mehr mit anderen Wegen verklebt.



<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

2018-04-04 18:38 GMT+02:00 "Christian Müller" <cmu...@gmx.de>:

> > Sent: Wed, 4 Apr 2018 17:38:23 +0200
> > From: "Florian Lohoff" <f...@zz.de>
> > To: "Christian Müller" <cmu...@gmx.de>
> > Cc: talk-de@openstreetmap.org
> > Subject: Re: [Talk-de] Flächen/Wege // Trolling in changesets
> >
> > Ich hatte ja in dem Thread auch ausgeführt das es ein Problem gibt mit
> > neumappern. Das Thema MP Relation und die Wege alle einzeln hinzufügen
> > ist noch eine viel größeres Pflegedesaster. Ich gebe dir Recht das das
> > eine total saubere Sache ist (Syntaktisch) - Aber leider ist das eben
> > für "gelegenheitsmapper" völlig ungeeignet.
>
> Und wieder und wieder werden Leute bevormundet, die du überhaupt nicht
> kennst, nie in deinem Leben gesehen hast, mit Behauptungen, die einzig
> und allein einem Bauchgefühl (und vielleicht ein paar Beobachtungen in
> den Daten) entspringen zu scheinen.
>
> Der "Gelegenheitsmapper", das ist so der "Ottonormalverbraucher" oder
> der "Kleine Mann", jeder will ihn kennen, nie hat ihn jemand gesehen
> oder verstanden.
>
> Wieviel Projekte wird das Internet noch sehen müssen, bevor sich der
> letzte von solchen Aussagen trennt?
>
> Du unterschlägst sowohl Intelligenz, Wissbegier, Neugier, Lernfähigkeit
> der freiwilligen Mapper, imho.  Vielleicht liegt dein Fokus auch zu sehr
> auf den vermeintlichen Problemen, anstatt zu sehen, dass eine ganze
> Menge an Edits eben nicht fehlerbehaftet ist.
>
>
> Gruß
> cmuelle8
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de
>
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Martin Koppenhoefer]

sent from a phone

> On 4. Apr 2018, at 18:23, Christian Müller  wrote:
> 
> Ok, das habe ich verstanden.  Du hast aber nicht verstanden, dass
> wir auch die neu gebildeten Flächen wiederum genauer mappen können,
> wenn wir nur genau genug hinschauen.  Und immer wieder
> ergeben sich dieselben Fragen:


ja, wobei sie vermutlich den meisten immer unwesentlicher erscheinen, je 
untergeordneter die Stellen sind.


> 
> Was ist dazwischen, sollten wir nicht eine Lücke lassen?
> Oder sollten wir die Lücke unterschlagen, weil sie unter
> gegebenen Umständen nicht relevant erscheint?


ich würde die Lücke lassen, wobei das auch Grenzen hat, z.B. mappe ich einen 
Zaun oder eine Mauer als einzige Linie, obwohl die natürlich in der Realität 
eine gewisse Dicke haben.


> 
> Vielleicht läuft auf der Waldgrenze ein Weg, der hat, bei genauer
> Betrachtung eine Fläche, also grenzt dann nicht Wald an Wiese,
> sondern Wald an Weg und Weg an Wiese, nicht?


ja, in diesem Fall würde ich 3 ways machen, einen für die Wiese, einen für den 
Weg und einen für den Waldrand. Die haben oft auch nicht genau dieselbe Form.

Du schriebst weiter oben, die geometrischen und Lagedetails seien komplett 
unwichtig, ich sehe das ganz anders, es gibt für Formen, Abweichungen, etc. 
normalerweise einen Grund, Grenzen und Flächen liegen zwar manchmal 
willkürlich, oft aber auch nicht.

Gruß,
Martin 
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Christian Müller]

> Sent: Wed, 4 Apr 2018 16:39:05 +0200 
> From: "Martin Koppenhoefer" <dieterdre...@gmail.com>
> To: "Openstreetmap allgemeines in Deutsch" <talk-de@openstreetmap.org>
> Subject: Re: [Talk-de] Flächen/Wege // Trolling in changesets
>
> D.H. wer den Zaun einzeichnen will muss zwangsläufig die Fläche mühsam von 
> der Straße trennen. Und wenn es da keinen Zaun gibt, irgendwas wird der 
> Mapper immer finden, was er da mappen will ;-)
> 
> Leben und leben lassen funktioniert am besten mit relativ wenigen, aktiven 
> Mappern, die sozusagen „ihr“ Gebiet haben (und einen bestimmten „Maßstab“ im 
> Kopf haben), aber wenn dann von vielen Leuten „wild“ Sachen ergänzt werden 
> (was wir ja gerade wollen), führt das oft zu einem Wulst (insbesondere von 
> Topologieproblemen).
> 

Es ist der technischen Entwicklung _und_ der Verfügbarkeit detaillierter 
Luftbilder geschuldet, dass oft keine Flächen mehr an Straßen geklebt werden.  
D.h. zum Einen ist es möglich, die Straßen- und Bahnanlagen als das zu 
Erfassen, was sie sind (Flächen) und zum Anderen ist es nicht mehr nötig, 
übermäßig darauf zu achten, dass alles in 8 kilobyte passt (mal übertrieben 
dargestellt).

Es ging hauptsächlich darum, aufzuzeigen, warum manche Daten so in der DB als 
Bestandsdaten vorhanden sind, wie sie es derzeit eben sind - und dass diese 
Varianten unter bestimmten Umständen (je nachdem was als Ziel angesehen wird) 
auch ihre Vorteile besitzen.  

OSM hat auch mehrmals den Fokus verschoben, eine reine Straßenkarte ist es 
schon lange nicht mehr.  Je mehr spezialisierte Details addiert werden, desto 
häufiger wird aber der Wunsch anzutreffen sein, vorgefilterte (oder 
umgerechnete) Datensätze zu nutzen.  OsmAnd z.B. errechnet seit längerer Zeit 
reine Straßenkarten und filtert
damit den ganzen Rest aus den Daten heraus.  Zusammen mit ein paar Algorithmen 
zur Knotenreduktion läuft das Ergebnis auch auf älteren, weniger 
leistungsfähigen Geräten und bedient damit ein breiteres Spektrum an 
Anwendungsfällen.

Und wer den Zaun einzeichnet, muss die Fläche nicht trennen, sofern er das 
nicht kann/will.  Diesen Job kann auch ein anderer Mapper übernehmen..


Gruß
cmuelle8

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Christian Müller]

> Sent: Wed, 4 Apr 2018 17:38:23 +0200
> From: "Florian Lohoff" <f...@zz.de>
> To: "Christian Müller" <cmu...@gmx.de>
> Cc: talk-de@openstreetmap.org
> Subject: Re: [Talk-de] Flächen/Wege // Trolling in changesets
>
> Ich hatte ja in dem Thread auch ausgeführt das es ein Problem gibt mit
> neumappern. Das Thema MP Relation und die Wege alle einzeln hinzufügen
> ist noch eine viel größeres Pflegedesaster. Ich gebe dir Recht das das
> eine total saubere Sache ist (Syntaktisch) - Aber leider ist das eben
> für "gelegenheitsmapper" völlig ungeeignet.

Und wieder und wieder werden Leute bevormundet, die du überhaupt nicht
kennst, nie in deinem Leben gesehen hast, mit Behauptungen, die einzig
und allein einem Bauchgefühl (und vielleicht ein paar Beobachtungen in
den Daten) entspringen zu scheinen.

Der "Gelegenheitsmapper", das ist so der "Ottonormalverbraucher" oder
der "Kleine Mann", jeder will ihn kennen, nie hat ihn jemand gesehen
oder verstanden.

Wieviel Projekte wird das Internet noch sehen müssen, bevor sich der
letzte von solchen Aussagen trennt?

Du unterschlägst sowohl Intelligenz, Wissbegier, Neugier, Lernfähigkeit
der freiwilligen Mapper, imho.  Vielleicht liegt dein Fokus auch zu sehr
auf den vermeintlichen Problemen, anstatt zu sehen, dass eine ganze
Menge an Edits eben nicht fehlerbehaftet ist.


Gruß
cmuelle8

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Christian Müller]

> Sent: Wed, 4 Apr 2018 16:22:05 +0200
> From: "Hartmut Holzgraefe" <hartmut.holzgra...@gmail.com>
> To: talk-de@openstreetmap.org
> Subject: Re: [Talk-de] Flächen/Wege // Trolling in changesets
>
> Verklebt man Flächen und Wege dann verschwindet eine eigentlich
> vorhandene Lücke.
> 
> Stoßen zwei Flächen dagegen tatsächlich direkt aneinander, zB.
> ein Waldstück und eine Wiese, dann ist es kein Problem wenn diese
> beiden sich eine Grenzlinie teilen. Darum geht es in diesem Thread
> aber nicht, sondern konkret um das "verkleben" von Objekten 
> unterschiedlicher Dimension: zweidimensionale Flächen mit
> eindimensional erfassten Stra0en und Wegen.

Ok, das habe ich verstanden.  Du hast aber nicht verstanden, dass
wir auch die neu gebildeten Flächen wiederum genauer mappen können,
wenn wir nur genau genug hinschauen.  Und immer wieder
ergeben sich dieselben Fragen:

Was ist dazwischen, sollten wir nicht eine Lücke lassen?
Oder sollten wir die Lücke unterschlagen, weil sie unter
gegebenen Umständen nicht relevant erscheint?

Vielleicht läuft auf der Waldgrenze ein Weg, der hat, bei genauer
Betrachtung eine Fläche, also grenzt dann nicht Wald an Wiese,
sondern Wald an Weg und Weg an Wiese, nicht?


"Eindimensional erfasst" heißt eben nicht "eindimensional vor Ort".
Das Wege, Straßen und Bahnlinien Fläche verbrauchen, wird einem
schon dann bewusst, wenn genügend Bäume für Straßen, Wege, Bahn-
linien, Stromtrassen, Pipelines, aber auch Feuerschutzstreifen
abgeholzt wurden.

Nochmal, das Problem ist eines der Abwägung:  Wieviel Detail soll
erfasst werden und wieviel Detail darf durch Abstraktion verloren
gehen!?

Wenn der Straßengraben, der ja i.d.R. linear an der Straße entlang
läuft, als Teil der (linear erfassten) Straße aufgefasst wird,
sprich er mit der Gesamtstraßen-Anlage gemeinsam abstrahiert
wird und der Straße eine Standardbreite (oder eine per tag er-
fasste) zugewiesen wurde, /dann/ ist es auch eine sinnvolle und
effiziente Repräsentation, die lineare Repräsentation der Gesamt-
anlage als Flächengrenze wiederzuverwenden.

Wie bereits gesagt, entsteht dadurch ein Fehler (abstraktions-
bedingt), der bei der Flächenberechnung aber z.B. dadurch min-
imiert werden kann, dass (Länge*getaggte Breite)/2 von der Be-
rechnung der Flächengröße der geklebten Fläche abgezogen werden
kann.  /Wenn/ alle Flächen so gemappt würden, dann ist das auch
programmatisch einfachst umzusetzen, dann programmiert man das
einmal und gut ist.

Soll der Straßengraben hingegen als separate Fläche erfasst
werden, weil festgestellt wurde, dass die Abstraktion zu stark
abstrahiert und oft nicht der Situation vor Ort entspricht,
dann braucht man eben ein paar Linien mehr:  Die vom Acker
zum Graben, die vom Graben zur Straßenkante.  Wird der Graben
mit riverbank=* erfasst, dann können das schon vier parallele
Linien sein:

Je nachdem wie genau man hinschaut, lassen sich also mehr und
mehr Flächen (und damit auch Flächengrenzen) identifizieren,
aber es ist Unsinn, eine Lücke herzustellen, ohne diese dann
auch als getaggte Fläche auszuzeichnen.

Es steht eine Gesamtfläche zum Mappen zur Verfügung und die
Frage ist, wie genau und wo man sie unterteilt, um Teilflächen
zu beschreiben.  Das kann z.B. grob mit "Harz", "Alpen" oder
"Wassereinzugsgebiet der Elbe" geschehen oder etwas genauer
mit "Berliner Stadtbibliothek".

Weder die (groben) Grenzen von Gebirgen, noch die genaueren
der Stadtbibliothek verschwinden dadurch, dass in ihren Gren-
zen weitere flächenhafte Objekte identifiziert werden (etwa
durch Indoor-Mapping der Stadtbibliothek oder der Erfassung
von einzelnen Forstgebieten oder Stauseen im "Harz").

Und auch das Phänomen, dass eine Fläche an eine andere an-
schließt, wird sich durch Lückenbildung (egal aus welcher
Motivation heraus) nicht egalisieren, wobei es unerheblich
ist, auf welcher Detailstufe dieses Phänomen untersucht
wird.  Man ziehe beispielhaft die naturräumliche Gliederung
Deutschlands oder anderer Länder zu rate.  Die hier benutzten
Grenzen bilden teilweise /Streifen/, die mehrere Kilometer
mächtig sind, die auf anderen Detailstufen weitere Flächen
enthalten, ohne dabei aber den Aspekt des "aneinandergeklebt"-
seins zu verlieren.


> > Du kannst den Missstand mit den overlapping ways beenden,
> > indem du MP bildest, die sich der geometrisch korrekt
> > eingetragenen Flächengrenzen(-teile) bedienen.
> 
> Das verstehe ich nicht, das verkompliziert die Sache doch eher
> noch mehr, wie wir an den immer wieder kaputt gehenden 
> Verwaltungsgrenzen und Küstenlinien regelmäßig leidvoll erfahren ...

Das ist zum Teil ein Bildungsproblem.  Es ist eben nicht zu
vermeiden, dass unerfahrene Nutzer auch mal etwas kaputt machen.

Zur Abhilfe gibt es mehrere Kommunikationswege, die Changeset-
Kommentarfunktion, das Wiki, etc. pp. - es wäre aber imho

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Florian Lohoff]

On Wed, Apr 04, 2018 at 04:16:39PM +0200, "Christian Müller" wrote:
> Vielleicht ist es besser zwischen
> 
> - allgemeinem "Verkleben" von Flächen
> 
> - "Verkleben" von Flächen mit highway=*
> 
> zu unterscheiden und zusätzlich zu erklären,
> ob "Verkleben" nur die Bildung von Flächen
> mit overlapping ways oder auch mit der Wie-
> derverwendung von ways in MP meint.  Imho
> wird derzeit sowohl das eine als auch das
> andere darunter verstanden, d.h.
> 
> nicht verkleben == "Luft" zwischen Flächen

Es ist noch differenzierter - 

- Verkleben von Flächen unterschiedlicher Dimension d.h.
  z.b. highway, waterway und Flächen landuse, landcover, leisure,
  natural, amenity

- Verkleben von Flächen unterschiedlicher klasse d.h. landuse mit
  leisure oder landuse mit amenity.

Beides versuche ich wo es nur geht zu vermeiden. Ein amenity=parking
in einem landuse=graveyard oder landuse=commercial versuche ich nicht
zu verbinden. Und wenn man nur genau genug hin sieht ist es meistens
auch geometrisch richtig das nicht zu verbinden. Und es ist für 
den "gelegenheitsmapper" auch viel klarer was gemeint ist.

Flo
-- 
Florian Lohoff f...@zz.de
 UTF-8 Test: The  ran after a , but the  ran away


signature.asc
Description: PGP signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Florian Lohoff]

On Wed, Apr 04, 2018 at 04:00:28PM +0200, "Christian Müller" wrote:
> 
> Du kannst den Missstand mit den overlapping ways beenden,
> indem du MP bildest, die sich der geometrisch korrekten
> eingetragenen Flächengrenzen(-teile) bedienen.
> 

Ich hatte ja in dem Thread auch ausgeführt das es ein Problem gibt mit
neumappern. Das Thema MP Relation und die Wege alle einzeln hinzufügen
ist noch eine viel größeres Pflegedesaster. Ich gebe dir Recht das das
eine total saubere Sache ist (Syntaktisch) - Aber leider ist das eben
für "gelegenheitsmapper" völlig ungeeignet.

Flo
-- 
Florian Lohoff f...@zz.de
 UTF-8 Test: The  ran after a , but the  ran away


signature.asc
Description: PGP signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Martin Koppenhoefer]

sent from a phone

> On 4. Apr 2018, at 15:43, Christian Müller  wrote:
> 
> Das Verkleben ist alternativlos!  Die Frage ist natürlich WO man verklebt
> _und_ welchen Detailgrad man anstrebt.


stimmt, was verbunden sein muss darf man natürlich auch nicht trennen, ich habe 
(in Deutschland) auch schon öfters gesehen, dass angrenzende Flächen jeweils 
eigene nodes hatten, die jeweils ganz nah nebeneinander standen, aber eben 
nicht verbunden waren. Das sehe ich auch als Problem.

Deine Aussage bezog sich vermutlich darauf, angrenzende Flächen mit dem highway 
zu verbinden, und da gebe ich dir Recht, dass das in bestimmten Maßstäben OK 
ist. In OSM haben wir aber keine Maßstäbe (außer dem, was wir mit der 
Koordinatengenauigkeit darstellen können, und was die Mapper eintragen wollen), 
zumindest ist das Mappen im Maßstab der Straße durchaus schon üblich, und da 
kollidiert das Generalisieren der Flächen damit, weil entweder der die Fläche 
begrenzende Zaun in der Straßenmitte läuft (und seine Form verloren geht), oder 
er läuft über die Fläche und nicht am Rand. 

D.H. wer den Zaun einzeichnen will muss zwangsläufig die Fläche mühsam von der 
Straße trennen. Und wenn es da keinen Zaun gibt, irgendwas wird der Mapper 
immer finden, was er da mappen will ;-)

Leben und leben lassen funktioniert am besten mit relativ wenigen, aktiven 
Mappern, die sozusagen „ihr“ Gebiet haben (und einen bestimmten „Maßstab“ im 
Kopf haben), aber wenn dann von vielen Leuten „wild“ Sachen ergänzt werden (was 
wir ja gerade wollen), führt das oft zu einem Wulst (insbesondere von 
Topologieproblemen).


Gruß,
Martin 
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Hartmut Holzgraefe]

On 04.04.2018 16:00, "Christian Müller" wrote:


Das Verkleben kannst du nicht beenden - was willst du in die
entstehenden Lücken tun?  Sind die dann nicht mehr Teil dieser
Welt?  Soll da Fugenmörtel rein?


es geht ja gerade um die Lücken. Die entstehen nicht erst dadurch
dass zwei Flächen nicht verbunden sind, sondern dadurch dass z-B.
zwischen zwei Feldern tatsächlich eine Lücke ist wenn da eine Straße
dazwischen verläuft.

Verklebt man Flächen und Wege dann verschwindet eine eigentlich
vorhandene Lücke.

Stoßen zwei Flächen dagegen tatsächlich direkt aneinander, zB.
ein Waldstück und eine Wiese, dann ist es kein Problem wenn diese
beiden sich eine Grenzlinie teilen. Darum geht es in diesem Thread
aber nicht, sondern konkret um das "verkleben" von Objekten 
unterschiedlicher Dimension: zweidimensionale Flächen mit

eindimensional erfassten Stra0en und Wegen.


Du kannst den Missstand mit den overlapping ways beenden,
indem du MP bildest, die sich der geometrisch korrekten
eingetragenen Flächengrenzen(-teile) bedienen.


Das verstehe ich nicht, das verkompliziert die Sache doch eher
noch mehr, wie wir an den immer wieder kaputt gehenden 
Verwaltungsgrenzen und Küstenlinien regelmäßig leidvoll erfahren ...


--
hartmut


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Christian Müller]

Vielleicht ist es besser zwischen

- allgemeinem "Verkleben" von Flächen

- "Verkleben" von Flächen mit highway=*

zu unterscheiden und zusätzlich zu erklären,
ob "Verkleben" nur die Bildung von Flächen
mit overlapping ways oder auch mit der Wie-
derverwendung von ways in MP meint.  Imho
wird derzeit sowohl das eine als auch das
andere darunter verstanden, d.h.

nicht verkleben == "Luft" zwischen Flächen


Gruß
cmuelle8

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Christian Müller]

> Sent: Wed, 4 Apr 2018 12:02:53 +0200 
> From: "Florian Lohoff" <f...@zz.de>
> To: Markus <liste12a4...@gmx.de>
> Cc: talk-de@openstreetmap.org
> Subject: Re: [Talk-de] Flächen/Wege // Trolling in changesets
>
> Eine Linie ist EIN Objekt und nicht 10 übereinander.

Eine Flächengrenze ist auch EIN Objekt, die 10 oder mehr oder
weniger Flächen begrenzt.

Das Verkleben kannst du nicht beenden - was willst du in die
entstehenden Lücken tun?  Sind die dann nicht mehr Teil dieser
Welt?  Soll da Fugenmörtel rein?

Du kannst den Missstand mit den overlapping ways beenden,
indem du MP bildest, die sich der geometrisch korrekten
eingetragenen Flächengrenzen(-teile) bedienen.


Gruß
cmuelle8

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Christian Müller]

> Sent: Wed, 4 Apr 2018 08:07:26 +0200 
> From: "Florian Lohoff" <f...@zz.de>
> To: "Frederik Ramm" <frede...@remote.org>
> Cc: talk-de@openstreetmap.org
> Subject: Re: [Talk-de] Flächen/Wege // Trolling in changesets
>
> > gibt nur Stress (denn jemand anders könnte mit gleichem Recht wieder
> > "ver-kleben").
> 
> Ich sehe das so ein bischen als eine fatale Entwicklung bei OSM. Es gibt
> stellen da traut sich keiner mehr dran. Die Neumapper aus Unwissenheit
> kleben noch zeugs dran und drüber. Sobald man verstanden hat was das
> alles ist geht der Durchschnittsmapper da nicht mehr dran - Sowas finde
> ich schade und ich empfinde das aufräumen als chance für neue mapper.

Vielen Dank für diesen amüsanten Beitrag, der sowohl historische Ent-
wicklungen, als auch mathematische Bezüge einmal mehr unter den Tisch
kehrt.

Das Verkleben ist alternativlos!  Die Frage ist natürlich WO man verklebt
_und_ welchen Detailgrad man anstrebt.

Wenn der Detailgrad hoch genug ist, trauen sich neue Mapper i.d.R. erstmal
nicht an ein Gebiet - da spielt es keine Rolle welche Methode angewandt
wurde.

/Weshalb/ wurde denn in der Vergangenheit verklebt?  Vielleicht weil die
technologische Entwicklung noch nicht so weit war, bzw. die technische
Ausstattung in der Breite eine andere, weniger leistungsfähige war?

Wer klebte, hat das i.d.R. aus /Effizienzgründen/ getan, denn damit
ließen sich oft mehrere parallele Linienzüge vermeiden.  Der topo-
logische Fehler, der damit in Kauf genommen wurde, war relativ klein
und bestand oft lediglich in vernachlässigten Straßengräben / -alleen
oder der Straßenbreite.

OSM war zudem anfangs als Straßenkarte ausgelegt, und schon jedesmal,
wenn es darum ging auch nur diese Straßen etwas detaillierter zu er-
fassen, beschäftigte sich jemand damit, wie man statt einer geometrischen
Lösung, eine tag-basierte verwenden könne - also, wie sich geographische
Lagedaten, die nicht näher interessieren, durch Schlagworte an den Linien-
zügen (ways) abstrahieren lassen.


Wenn ein Acker zwischen drei Straßen lag bzw. liegt und aus eben diesen
Effizienzgründen die Straßengräben vernachlässigt wurden, dann war eine
verklebte Version dieses Feldes evtl. geometrisch nicht völlig korrekt,
aber die Wiederverwendung dieser Straßen als Grenzen sowohl eine einfache,
sinnvolle und effiziente Ergänzung der Daten, um die Landnutzung der
Fläche anzuzeigen, die von diesen drei Straßen /begrenzt/ wurde.

Mit der Miniaturisierung rückte auch bei OSM das credo /less is more/
in den Hintergrund und Mapper begannen, die Details der Karte weniger
als Abstraktion und mehr als Abbild der Realität (lies: des Luft- oder
Satellitenbildes) wiederzugeben.

Wenn wir aber mehr Flächen in die DB eintragen, weil wir Detail, das
vorher durch den Mapping-Prozess wegabstrahiert wurde, wiedergeben
wollen, dann /verschieben/ und /vermehren/ wir lediglich die abge-
bildeten Flächengrenzen, die sich in der Realität oder von einem
Luftbild ableiten lassen.

Den Logos, dass eine Fläche an eine oder mehrere andere /grenzt/
lösen wir hingegen nicht auf (egal in welche Detailstufe wir gehen,
wir können immer wieder Flächen- oder auch Raumgrenzen finden bzw.
ableiten von dem was wir auf dieser Detailstufe vorfinden).

Es ist schlichtweg falsch, eine Fläche losgelöst von ihren Nachbar-
flächen zu betrachten, denn ihre Grenzen sind auch die der Nachbar-
flächen.  Oder anders gesagt, wir würden eine Fläche ohne die an-
grenzenden Nachbarn gar nicht als solche wahrnehmen können.


In OSM sind derzeit drei wesentliche Methoden beobachtbar, die ver-
suchen diesen Sachverhalt abzubilden:

1) ein Abschnitt (way) der sowohl Fläche A und B begrenzt, nimmt in der
Rolle 'outer' als Mitglied in den MP-Relationen für je A und B teil.

2) Für A und B werden zwei Wege (ways) benutzt (overlapping ways),
die sich eine Knotenfolge teilen (diese Folge wird in der Daten-
struktur für diese ways wiederholt)

3) Zwei ways mit voneinander unabhängigen Knoten bzw. -folgen werden
als Grenzen gezeichnet; die gemeinsame Flächengrenze wird durch zwei
Linien approximiert - mal ist Luft dazwischen, mal schneiden sich
Wegsegmente und die Flächen überlappen sich unabsichtlich etwas.


M.M.n. ist 1) die zu bevorzugende Variante, um Sachverhalte vor Ort
und am Boden abzubilden.  Es folgt den "best practices" im OSM Wiki.
Dort wird empfohlen, für jedes zu erfassende Objekt der Realität,
genau ein entsprechendes Objekt in der Datenbank anzulegen:

Die Flächengrenze gibt es genau einmal, also ist sie mit 1) auch nur
1x in der DB drin.  2) hat zwar noch keinen geometrischen Fehler,
aber die Rückübersetzung ist mehrdeutig:  sind zwei überlappende
Wege nun der gleiche Weg in der Realität oder nicht?  Sie könnten
schließlich auch in unterschiedlicher Höhe liegen (oder sich in
der Höhe kreuzen).

3) schließlich ist zwar oft (gern?) genutzt, aber sowohl wartungs-
technisch als auch geometrisch

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Florian Lohoff]

Hi Markus,

On Wed, Apr 04, 2018 at 10:45:34AM +0200, Markus wrote:
> Hallo Frederik, hallo Florian,

> Wenn eine bestimmte Ausprägung aber zu Chaos und Entropie führt,
> und dies zunehmend unbewältigbar scheint und zu entsprechendem Frust und
> Verlust von Motivation und Mitarbeit führt, dann läuft etwas falsch.
> Und wir sollten uns dem rechtzeitig und grundlegend annehmen.

Das ist so meine Wahrnehmung. Eine Zeitlang habe ich mal jede Changeset
durchgesehen hier in der Gegend und habe dann gerne kommentiert - Oft
kamen dann wirklich dinge zurück wie "Ich weiss gar nicht wie du das
meinst" oder "Das bekomme ich nicht hin - kanst du das reparieren."

Mich hat das zur Überzeugung gebracht das ich mit 10 Jahren OSM einfach
auch "Betriebsblind" bin - Ich gehe immer so davon aus das was ich da
verstanden habe und hin bekomme doch jeder hinbekommen kann. Dem ist
aber eben nicht so. Ich kann so ein Liniengewirr im Kopf sortieren und
nach und nach auseinanderdröseln - Der Neumapper kann das nicht - Der
"malt" drüber oder gibt auf.

Deshalb bin ich auch so ein großer Freund davon das verkleben zu
beenden. Für mich sorgt das für klarere Strukturen in den Daten die
jeder verstehen kann. Eine Linie ist EIN Objekt und nicht 10
übereinander.

> Also bleiben nur drei Möglichkeiten:
> entweder zurück zum alten falschen Zustand,
> oder alles auseinanderdröseln - und mit viel Aufwand darauf achten, dass
> ich keine Verschlimmbesserungen erzeuge - und dann meine (kleine)
> Verbesserung einzutragen,
> oder frustriert den verschlimmbesserten Zustand hochladen (in der
> vermutlich irrigen Annahme, dass das da schon "irgendjemand" der sich
> besser auskennt/mehr Zeit hat wieder aufräumt).

Ich empfinde das oft als "trauen". Jemand mit breitem Kreuz der einfach
dann auch mal "Delete" drückt und dann sich zur not auch mal anmachen
lässt was das soll.

> Auch für mich ist das sehr hilfreich!
> In einer aufgeräumten Gegend helfe ich gern und ergänze Neues :-)
> 
> _Ursachen_
> Parallel zu solchen Aufräum-Aktionen sollten wir uns überlegen, was die
> Ursachen für dieses Chaos sind und wie wir verhindern können, dass nicht
> noch mehr Chaos erzeugt wird.
> 
> Mögliche Ursachen für "Verkleben":
> 1. Mappen für den Renderer
>(damit die Karte "schön" wird, keine "weissen Flächen" hat)
> 2. fehlende Regeln (weil irgendwie verpönt?) für Best Practice
>und fehlende Erklärungen, warum man Dinge so und nicht anders macht

Das mit den best practices geht ja heute schon "schief". Es gibt ja so
ein how-to in dem u.a. erklärt wird das man bei parallelen Linien die
Nodes auch entsprechend immer in allen Linien hat - Klappt auch nur
begrenzt.
 
> Viel wäre schon geholfen, wenn wir folgende Regeln hätten:
> 
> - Linien nicht mit Flächen verbinden
> - Linien nur mit gleichartigen Linien verbinden
> - Flächen nur mit gleichartigen Flächen verbinden
> - Ausnahmen genau und nachvollziehbar definieren und begründen
> - für Linien in Flächen die Hierarchie definieren
> - für Flächen in Flächen die Hierarchie definieren
> 
> (und das genau zu definieren ist vermutlich ziemlich viel Arbeit,
> inhaltlich - und vermutlich auch emotional)

Ich finde das hat was mit Vorbildfunktion zu tun. In einer Gegend in der
es sehr aufgeräumt ist wird typischerweise sehr aufgeräumt weiter
gemappt. In den gegenden wo eh alles übereinander ist wird halt genau so
weiter gemacht. 

Flo
-- 
Florian Lohoff f...@zz.de
 UTF-8 Test: The  ran after a , but the  ran away


signature.asc
Description: PGP signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Martin Koppenhoefer]

Am 4. April 2018 um 08:07 schrieb Florian Lohoff :

>
> Wenn ich da was auf mache endet das meistens in einer Stundenlangen
> Aufräumaktion mit Verkleinerung der Landuses. Korrektur der Lage und
> Topologie. Dann plumpsen da noch so 10-20 Bugs raus mit dingen die sich
> aus den Luftbildern nicht klären lassen.
>


+1, "zu große" Landuses sind auch ein Thema. M.E. spricht nichts dagegen,
landuses so klein wie möglich/nötig zu mappen, z.B. Straßenflächen
möglichst nicht mit reinzunehmen. Das ist zum einen detaillierter, und zum
anderen viel leichter bearbeitbar und besser durchschaubar.



>
> Und man findet halt auch nur beim Entkleben schon Tonnen an Bugs. Wo
> dadurch das das jetzt 10 Jahre da so rumgelungert hat diverse Mapper
> einfach drüber oder daneben die selben dinge noch einmal eingezeichnet
> haben weil eben kein Objekt mit der Form da war. Doppelt und Dreifache
> Gebäude, Tracks, Hauszufahrten weil die eben mit beliebigen Flächen
> verbunden, deformiert wurden und dann erneut eingezeichnet.
>


ja, Hecken und Zäune, die mitten durch Flächen zu gehen scheinen, weil das
Feld bis zu Straßenmitte gezeichnet ist.


>
> Ich sehe das so ein bischen als eine fatale Entwicklung bei OSM. Es gibt
> stellen da traut sich keiner mehr dran. Die Neumapper aus Unwissenheit
> kleben noch zeugs dran und drüber. Sobald man verstanden hat was das
> alles ist geht der Durchschnittsmapper da nicht mehr dran - Sowas finde
> ich schade und ich empfinde das aufräumen als chance für neue mapper.



+1. Was schon da ist, färbt auch wieder auf neue Beiträge ab, weil man sich
als neuer Mapper normalerweise erstmal umsieht, was bereits wie gemacht ist
(im eigenen Umfeld, das man kennt).

Gruß,
Martin
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Markus]

Hallo Frederik, hallo Florian,

>> Eigentlich hatten wir diesbezüglich immer eine Art "Waffenstillstand" ->> 
>> wer neu mappt, sucht sich aus, welchen Stil er möchte, und wer eine>>
Gegend "generalüberholt", kann das vielleicht auch tun, aber
"ent-kleben>> um des Ent-klebens willen", d.h. wenn gar keine neue
Information>> dazukommt ausser dass halt ent-klebt wird, das sollte man
nicht tun, das>> gibt nur Stress (denn jemand anders könnte mit gleichem
Recht wieder>> "ver-kleben").
Auch ich bin sehr für Freiheit.
Denn Freiheit ist eine wesentliche Voraussetzung für Kreativität.

Wenn eine bestimmte Ausprägung aber zu Chaos und Entropie führt,
und dies zunehmend unbewältigbar scheint und zu entsprechendem Frust und
Verlust von Motivation und Mitarbeit führt, dann läuft etwas falsch.
Und wir sollten uns dem rechtzeitig und grundlegend annehmen.

Neu-Mapper sind nach meiner Erfahrung immer begeistert und motiviert.
Und gleichzeitig erschlagen von der Komplexität unseres Systems.
Sie wollen es gern "richtig" machen, scheitern aber an fehlender oder
schwer zu findender oder unverständlicher Information im Wiki.

Florian, damit beschreibst Du ein grösseres Übel ziemlich treffend:

> endet meistens in einer stundenlangen Aufräumaktion 
> Und man findet beim Entkleben schon Tonnen an Bugs.
> Es gibt Stellen da traut sich keiner mehr dran. 
> Die Neumapper aus Unwissenheit kleben noch Zeugs dran und drüber.

Auch ich habe zunehmend weniger Lust, etwas einzutragen :-(
Kaum verschiebe ich etwas, ändern sich die damit verklebten Objekte.
Sich kongruent überlagernde aber nicht identische Objekte sind ein
ähnliches Übel.

Also bleiben nur drei Möglichkeiten:
entweder zurück zum alten falschen Zustand,
oder alles auseinanderdröseln - und mit viel Aufwand darauf achten, dass
ich keine Verschlimmbesserungen erzeuge - und dann meine (kleine)
Verbesserung einzutragen,
oder frustriert den verschlimmbesserten Zustand hochladen (in der
vermutlich irrigen Annahme, dass das da schon "irgendjemand" der sich
besser auskennt/mehr Zeit hat wieder aufräumt).

> ich empfinde das Aufräumen als Chance für neue Mapper.

Auch für mich ist das sehr hilfreich!
In einer aufgeräumten Gegend helfe ich gern und ergänze Neues :-)

_Ursachen_
Parallel zu solchen Aufräum-Aktionen sollten wir uns überlegen, was die
Ursachen für dieses Chaos sind und wie wir verhindern können, dass nicht
noch mehr Chaos erzeugt wird.

Mögliche Ursachen für "Verkleben":
1. Mappen für den Renderer
   (damit die Karte "schön" wird, keine "weissen Flächen" hat)
2. fehlende Regeln (weil irgendwie verpönt?) für Best Practice
   und fehlende Erklärungen, warum man Dinge so und nicht anders macht

Viel wäre schon geholfen, wenn wir folgende Regeln hätten:

- Linien nicht mit Flächen verbinden
- Linien nur mit gleichartigen Linien verbinden
- Flächen nur mit gleichartigen Flächen verbinden
- Ausnahmen genau und nachvollziehbar definieren und begründen
- für Linien in Flächen die Hierarchie definieren
- für Flächen in Flächen die Hierarchie definieren

(und das genau zu definieren ist vermutlich ziemlich viel Arbeit,
inhaltlich - und vermutlich auch emotional)

Mit herzlichem Gruss,
Markus

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Martin Koppenhoefer]

Am 3. April 2018 um 00:59 schrieb Frederik Ramm :

> Eigentlich hatten wir diesbezüglich immer eine Art "Waffenstillstand" -
> wer neu mappt, sucht sich aus, welchen Stil er möchte, und wer eine
> Gegend "generalüberholt", kann das vielleicht auch tun,



d.h. er hätte schreiben sollen, "ich bin gerade dabei, mein Umfeld
'generalzuüberholen' und in diesem Zug entklebe ich auch Flächen seitlich
von Straßen mit deren Mittellinie?



> aber "ent-kleben
> um des Ent-klebens willen", d.h. wenn gar keine neue Information
> dazukommt ausser dass halt ent-klebt wird, das sollte man nicht tun,



sofern man die "entklebten" Flächenränder nicht in der Straßenmitte lässt
sondern an den tatsächlichen Rand der Fläche schiebt, kommt ja
grundsätzlich Information dazu.

Ich hatte Florian so verstanden, dass es ihm lieber wäre, anstatt weiterhin
in einem Kompromiss zu leben, wo man keine klare Empfehlung abgibt, mal
wieder ein allgemeines Meinungsbild einzuholen, ob man sich vielleicht
diesesmal auf eine Lösung einigen kann, und da überwiegend nicht verklebt
wird, böte sich dieser Stil an.
Das "Verkleben" hat m.E. vorwiegend Nachteile: es ist eine Generalisierung
die ab einem bestimmten Maßstab nicht mehr funktioniert, die Flächen werden
dadurch zu groß abgebildet, Objekte auf der Straße und in der Nähe
fälschlicherweise in die Fläche eingeschlossen (z.B. Briefkästen und
Telefonzellen), und im Gegenzug erhält man eine "aufgeräumtere" Karte
(sofern nicht alles detailliert gemappt ist, sieht es sauberer aus, weil
keine "Restflächen" zurückbleiben, wobei unterschlagen wird, dass es diese
Restflächen meistens auch wirklich gibt). Es wurde auch schon angeführt sei
es vermeintlich topologisch richtiger, weil die Straßen ja wirklich bis zur
Fläche gingen, aber gleichzeitig verbindet man so (die gegenüberliegenden)
Flächen miteinander, die eigentlich durch die Straßenfläche getrennt sind,
fügt also einen Topologiefehler hinzu. Letzteres sind zugegebenermaßen
Definitions- und Interpretationsfragen, wenn man es aufwändig haben will,
kann man die Topologiesachen analysieren und berechnen (z.B. annehmen, dass
Straßen immer eine Ausdehnung haben müssen, und sich nie auf den seitlichen
landuses und anderen Flächen befinden können, was aber nicht unbedingt
weltweit immer stimmen muss) , aber die fehlende Information der wirklichen
Flächengrenze kann man nur raten.

Vor allem  stehen dem Probleme beim Editing gegenüber (umständlicher und
zeitraubender, Verfeinerungen einzubauen), die leicht zu Folgefehlern
(falsche und ggf. fehlende Verbindungen im Graph) führen, und der erhöhte
Bearbeitungsaufwand lässt manchen Mapper schon vor dem Start davor
zurückschrecken, überhaupt Verfeinerungen zu mappen.

Falls man keine Einigung erzielt könnte man auch intensiver landuse=highway
(i.e. Straßenflächen, -parzellen) oder auch area:highway=* (befahrbare
Straßenfläche) mappen, dann würde sich das Problem von selbst lösen. ;-)

Gruß.
Martin
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Florian Lohoff]

On Tue, Apr 03, 2018 at 12:59:36AM +0200, Frederik Ramm wrote:
> Hi,
> 
> On 04/02/2018 12:03 AM, Florian Lohoff wrote:
> > ich habe vor ein paar Wochen angefangen in meinem Dunstkreis
> > (Ostwestalen-Lippe) Systematisch alle "verklebten Flächen und Wege"
> > aufzulösen. 
> 
> Eigentlich hatten wir diesbezüglich immer eine Art "Waffenstillstand" -
> wer neu mappt, sucht sich aus, welchen Stil er möchte, und wer eine
> Gegend "generalüberholt", kann das vielleicht auch tun, aber "ent-kleben
> um des Ent-klebens willen", d.h. wenn gar keine neue Information
> dazukommt ausser dass halt ent-klebt wird, das sollte man nicht tun, das
> gibt nur Stress (denn jemand anders könnte mit gleichem Recht wieder
> "ver-kleben").

Für mich ist die Auswertung so 2 Aspekte:

- Zum einen will ich entdecken wo jemand anfängt neue verklebungen
  einzuführen, absichtlich oder unbeabsichtigt. Die schreibe ich dann
  an.

- Zum anderen ist das ein schöner Hint wo man mal hin gucken kann. Denn
  die stellen die ich gerade damit finde sind oft Jahrlang ungepflegt. 
  Aus Bing mal riesige Flächen übernommen nur damit die Karte endlich
  eine andere Hintergrundfarbe bekommt.

Wenn ich da was auf mache endet das meistens in einer Stundenlangen 
Aufräumaktion mit Verkleinerung der Landuses. Korrektur der Lage und
Topologie. Dann plumpsen da noch so 10-20 Bugs raus mit dingen die sich
aus den Luftbildern nicht klären lassen.

Und man findet halt auch nur beim Entkleben schon Tonnen an Bugs. Wo
dadurch das das jetzt 10 Jahre da so rumgelungert hat diverse Mapper
einfach drüber oder daneben die selben dinge noch einmal eingezeichnet
haben weil eben kein Objekt mit der Form da war. Doppelt und Dreifache
Gebäude, Tracks, Hauszufahrten weil die eben mit beliebigen Flächen
verbunden, deformiert wurden und dann erneut eingezeichnet.

Um es polemisch auszudrücken: Das Verkleben ist die erste Zigarette die
jemand auf den Boden fallen lässt und wenn man nur lange genug wartet
liegt da irgendwann eine halbe Wohnungseinrichtung daneben.

Ich habe auch das Gefühl wenn dann erstmal so das "Chaos" Einzug
gehalten hat und da so 10-20 Flächen und Wege wild über, unter und
nebeneinander entstanden sind und alles irgendwie so semi miteinander
verbunden ist und Sinnfrei überlappt dann traut sich da keiner mehr dran. 
Da kommt keiner und versucht das a la Sisyphos auseinander zu klamüsern.
Manchmal hilft halt nur ein "beherztes Delete" und neu machen. 

Ich sehe das so ein bischen als eine fatale Entwicklung bei OSM. Es gibt
stellen da traut sich keiner mehr dran. Die Neumapper aus Unwissenheit
kleben noch zeugs dran und drüber. Sobald man verstanden hat was das
alles ist geht der Durchschnittsmapper da nicht mehr dran - Sowas finde
ich schade und ich empfinde das aufräumen als chance für neue mapper.

Flo
-- 
Florian Lohoff f...@zz.de
 UTF-8 Test: The  ran after a , but the  ran away


signature.asc
Description: PGP signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Frederik Ramm]

Hi,

On 04/02/2018 12:03 AM, Florian Lohoff wrote:
> ich habe vor ein paar Wochen angefangen in meinem Dunstkreis
> (Ostwestalen-Lippe) Systematisch alle "verklebten Flächen und Wege"
> aufzulösen. 

Eigentlich hatten wir diesbezüglich immer eine Art "Waffenstillstand" -
wer neu mappt, sucht sich aus, welchen Stil er möchte, und wer eine
Gegend "generalüberholt", kann das vielleicht auch tun, aber "ent-kleben
um des Ent-klebens willen", d.h. wenn gar keine neue Information
dazukommt ausser dass halt ent-klebt wird, das sollte man nicht tun, das
gibt nur Stress (denn jemand anders könnte mit gleichem Recht wieder
"ver-kleben").

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Florian Lohoff]

Hi,

On Mon, Apr 02, 2018 at 06:03:33PM +0200, Mark Obrembalski wrote:
> Na ja, offenbar hält er das Abändern ja für nicht angebracht und möchte
> irgendwie dagegen protestieren (immerhin setzt er die Änderungen nicht
> zurück). Dass er es einfach schweigend hinnimmt, kann man kaum von ihm
> erwarten. Statt der Changesets wären aber sicher die Mailingliste, das Forum
> oder die passenden Diskussionsseiten im Wiki bessere Plätze, diese ja eher
> Grundsatzfragen betreffende Auseinandersetzung zu führen. Es wäre gut, wenn
> es gelänge, sie an einen dieser Plätze (oder mehrere) zu bringen.

Hab ich ja ihm alles schonmal geschrieben. Das die Changesets der
falsche Weg sind - und das es keinen Konsenz zum verkleben gibt, wir als
Ostwestfalen uns aber vor Jahren schon klar gegen das verkleben gestellt
haben. Interessiert alles nicht - Es wird trotzdem jeder changeset
Kommentar von mir kommentiert.

> Persönlich bin ich jedenfalls bei Straßen eindeutig fürs Nichtverkleben mit
> dem Way. Eigentlich sind die ja meist breit genug, um eine eigene Fläche zu
> bekommen (zu der dann auch z.B. ein Straßengraben, ein straßenbegleitender
> Rad- oder Fußweg etc. gehört), was ja manchmal auch schon umgesetzt wird.
> Klar, wenn eine schmale Straße durch den wilden Wald führt, kann man sich
> die Fläche auch sparen. Da reichen ja dann oft auch noch die Baumkronen
> weitgehend über die Straße.

Mit Augenmaß eben. Meine Erfahrung sagt halt das da wo verklebt wird
auch noch so einiges andere Krumm ist. Da wird lieber ein
landuse=residential 2km in einem Haarnadeldünnen Zweig der Landstraße
entlang gezogen anstatt 2 kleine Flächen zu machen.

Und wenn ich sowas auf mache und dann 20 Linien sehe die sich alle im
spitzen Winkel irgendwo Kreuzen dann weiss ich das das an der Stelle
eine lange Session wird die ganze nodes und linien mal so zu sortieren 
das da nix verklebt ist und die landuses nicht willkürlich überlappen
etc.

Auch noch so eine Auswertung die ich mal machen wollte. Beliebige Linien
die sich im spitzen Winkel z.b. mehr als 120° Kreuzen. Ich wette
da leuchtet dann "Pflegebedürftige" Bereiche in der Karte hellrot auf. 

Oder einfach mal landuses markieren die mehr als 2-3ha haben - Ist
natürlich Regional sehr unterschiedlichen. In Mecklenburg Vorpommern hat
man dann jede menge false positives - in OWL haben wir so kleine Felder
das da vermutlich die ganzen teilungsbedürftigen Landuses aufpoppen die
mal irgendwann zu Bing zeiten großzügig eingezeichnet wurden.

Alles keine "Hard facts" - aber wenn man diese Soft-Facts mal nimmt, 
auswertet und als heat map aufträgt dann denke ich das man spannende
Bereiche identifizieren kann.

Flo
-- 
Florian Lohoff f...@zz.de
 UTF-8 Test: The  ran after a , but the  ran away


signature.asc
Description: PGP signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Florian Lohoff]

On Mon, Apr 02, 2018 at 05:14:33PM +0200, Michael Reichert wrote:
> Halb-OT: Hat eigentlich schon einmal jemand™ untersucht, ob das
> Verkleben oder das Nichtverkleben in Deutschland bezogen auf die Fläche,
> die Anzahl der Objekte und die Anzahl der Benutzer dominierend sind?

Nicht verkleben ist dominant.

Ich habe mir ja software mit libosmium geschrieben die ein pbf
file auswertet und eine sqlite schreibt mit den ganzen "segmenten"
die verklebt sind (Also immer weg zwischen 2 nodes).

Für Ostwestalen-Lippe kann ich deutlich sagen das nicht verkleben
~95% sind - Die Bereiche die "rot leuchten" sind immer "einzelne"
User d.h. ein Dominanter Mapper der ein Dorf/Stadt quasi im Alleingang
gemacht hat. Da gabs dann keine Diskussion.

Um mal eine Näherung zu wagen:
   
flo@p4:~/projects/osm/libosmium/examples$ ./osmium_count 
../../localosm/detmold-regbez-latest.osm.pbf 
Nodes: 9174000
Ways: 1481201
Relations: 16224

Memory used: 1362 MBytes

D.h. wir haben in Ostwestfalen-Lippe 9.1Mio Nodes und 1.4Mio Wege.

Ich habe aktuell 24000 Segmente die verklebt sind d.h. weg zwischen
2 nodes. Daran sieht man wie wenig eigentlich verklebt wird. 

Mit verkleben meine ich highway/waterway - d.h. wirklich ways die mit
Flächen verklebt sind - also landuse, landcover, amenity, leisure.

"Verklebt" werden find ich so semi okay mit boundarys wobei ich da auch 
glaube das die allermeisten Highways die mit Boundarys verklebt sind die
boundary falsch ist. Es gibt ja keine Straße bei der links Kommune A
und auf der rechten Seite Kommune B Straßenunterhaltungspflichtig ist.
Die haben das dann typischerweise geklärt wer das macht und auf wessen
"Grund" die Straße errichtet wird. Da hat nur der mapper es "gut
gemeint" und vermutet das die Grenze die Straßenmitte ist.

Flo
-- 
Florian Lohoff f...@zz.de
 UTF-8 Test: The  ran after a , but the  ran away


signature.asc
Description: PGP signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Mark Obrembalski]

Am 02.04.2018 um 17:14 schrieb Michael Reichert:

Hallo Flo,

Am 2018-04-02 um 00:03 schrieb Florian Lohoff:

Die letzten Changesets sind jeweils von einem unbeteiligten Mapper
mal mehr oder minder freundlich kommentiert worden ich möge es bitte
unterlassen meine Bemühungen als Mehrheitsmeinung darzustellen bzw
meine Tätigkeit wird als "Desinformationskampagne" dargestellt.

Der letzte Changeset wo er selber nochmal alle weiteren Changesets
verlinkt hat:

https://www.openstreetmap.org/changeset/57715696

Mal davon abgesehen das ich keine Argumente erkennen kann empfinde ich es
mittlerweile als ärgerlich hier so verfolgt zu werden. Unbeteiligte
Mapper werden hier in "Geiselhaft" genommen und in Diskussion
zwangsweise hineingezogen.


Ich kann deinen Frust nachvollziehen und empfinde das Verhalten von
Benutzer OF0 auch als nervig. Er täte gut daran, die Dinge einfach mal
zu ignorieren. Ich hoffe mal, dass diese Einsicht von alleine kommt.


Na ja, offenbar hält er das Abändern ja für nicht angebracht und möchte 
irgendwie dagegen protestieren (immerhin setzt er die Änderungen nicht 
zurück). Dass er es einfach schweigend hinnimmt, kann man kaum von ihm 
erwarten. Statt der Changesets wären aber sicher die Mailingliste, das 
Forum oder die passenden Diskussionsseiten im Wiki bessere Plätze, diese 
ja eher Grundsatzfragen betreffende Auseinandersetzung zu führen. Es 
wäre gut, wenn es gelänge, sie an einen dieser Plätze (oder mehrere) zu 
bringen.


Persönlich bin ich jedenfalls bei Straßen eindeutig fürs Nichtverkleben 
mit dem Way. Eigentlich sind die ja meist breit genug, um eine eigene 
Fläche zu bekommen (zu der dann auch z.B. ein Straßengraben, ein 
straßenbegleitender Rad- oder Fußweg etc. gehört), was ja manchmal auch 
schon umgesetzt wird. Klar, wenn eine schmale Straße durch den wilden 
Wald führt, kann man sich die Fläche auch sparen. Da reichen ja dann oft 
auch noch die Baumkronen weitgehend über die Straße.


Gruß,
Mark

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Michael Reichert]

Hallo Flo,

Am 2018-04-02 um 00:03 schrieb Florian Lohoff:
> Die letzten Changesets sind jeweils von einem unbeteiligten Mapper
> mal mehr oder minder freundlich kommentiert worden ich möge es bitte
> unterlassen meine Bemühungen als Mehrheitsmeinung darzustellen bzw
> meine Tätigkeit wird als "Desinformationskampagne" dargestellt.
> 
> Der letzte Changeset wo er selber nochmal alle weiteren Changesets
> verlinkt hat:
> 
> https://www.openstreetmap.org/changeset/57715696
> 
> Mal davon abgesehen das ich keine Argumente erkennen kann empfinde ich es
> mittlerweile als ärgerlich hier so verfolgt zu werden. Unbeteiligte
> Mapper werden hier in "Geiselhaft" genommen und in Diskussion
> zwangsweise hineingezogen.

Ich kann deinen Frust nachvollziehen und empfinde das Verhalten von
Benutzer OF0 auch als nervig. Er täte gut daran, die Dinge einfach mal
zu ignorieren. Ich hoffe mal, dass diese Einsicht von alleine kommt.

Halb-OT: Hat eigentlich schon einmal jemand™ untersucht, ob das
Verkleben oder das Nichtverkleben in Deutschland bezogen auf die Fläche,
die Anzahl der Objekte und die Anzahl der Benutzer dominierend sind?

Viele Grüße

Michael


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de