Re: [Talk-de] Androhung von Benutzersperren für Verklebe-Ideologie

[Christian Müller]

Amen.  Das ist halt deine Meinung.
Aber die ist so fest wie sie fester
nicht sein kann!?

Wiederholend, was schon gesagt war:
Es hängt eben davon ab, wie die Daten durch
das Modell repräsentiert werden.  Solange eine
(Mittel-)Linie ein flächenhaftes Objekt _ge-
neralisiert_, solange besteht eben auch die
Möglichkeit, sie in bestimmte Beziehungen zu
anderen flächenhaften Objekten zu setzen,
die unter Berücksichtigung der jew. gültigen
Interpretation alle Sinn ergeben und "richtig"
sind.

Wenn das alles so wäre, wie du es dir vorstellst,
und also generell, total, absolut und jederzeit
falsch ist und ein Verkleben also tatsächlich sach-
unbezogen und damit allgemeingültig falsch ist,
warum hast du dann nicht längst den Universal-Patch
für das Problem geschrieben, der programmatisch einen
Upload der in deinen Augen falschen Topologien ver-
hindert?

Es ist wiederholt gesagt sinnlos, das weiter zu
diskutieren, solange das Datenmodell definitorisch
offen für mehrere Interpretationen ist.  Was du be-
klagst, ist diese Offenheit:  Du hättest keinen Grund
zur Klage, wenn programmatisch ein Verbot bestünde,
die von dir monierten Geometrien überhaupt erst hoch-
zuladen (d.h. Prüfung bei Upload in die DB).  Allein
das dies in den letzten Jahren nicht geschehen ist,
zeigt doch, dass deine Meinung offenbar nicht in so-
weit geteilt wird, dass sie für ein von Konsens ge-
tragenem Verbot ausreicht!?

Der Grad der Perfektion, den du anstrebst, ist doch
ganz offenbar leichter erreichbar, wenn die deiner
Meinung nach falschen Geometrien gar nicht erst hoch-
ladbar sind.  Um dieses Ziel zu verfolgen könnte man
m.E. das Datenmodell stärker axiomatisieren und insbes.
Vorgaben machen, wie bestimmte Grade der Generalisierung
geographischer Features interagieren dürfen.

Dafür zu werben, dass etwas, das technisch funktioniert
nicht genutzt werden soll, das nach Maßgabe der Inter-
pretation anderer Mitwirkender nicht IMMER falsch ist,
kann nur ein Kampf gegen Windmühlen sein.


Jedes Beitragen von Daten in OSM ist fehlerbehaftet, vor-
sätzlich und generalisierend!  Solche Plattitüden bringen
dich m.E. nicht weiter.  Wenn du an der Gesamtsituation
etwas ändern und für bestimmte Datenlagen Verbote auf-
stellen willst, kannst du die m.E. nur sinnvoll mit soft-
wareseitigen Umstellungen durchsetzen.  Da ich nicht die
Mehrheit bin, eine solche Umstellung in OSM aber mehr-
heitsfähig sein müsste, ist es eigentlich unerheblich ob
du meine Stimme für ein solches Unterfangen bekommst und
ob, wann, wo und wie ich Daten ver- oder entklebe.


Gruß

> On Mon, Oct 22, 2018 at 03:28:59PM +0200, "Christian Müller" wrote:
> 
> Verkleben ist das vorsätzliche hinzufügen von Fehlern zum zwecke
> der Generalisierung.
> 
> Flo

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

Re: [Talk-de] Androhung von Benutzersperren für Verklebe-Ideologie

[Christian Müller]

M.E. ist deine Darstellung übertrieben und du unterschlägst,
dass OSM ein Community-Projekt ist und erst nachrangig nackte
Wissenschaft.

Außerdem:  Egal wie genau deine Messinstrumente sind, du kannst
nie mit Sicherheit sagen, dass es keine genaueren geben kann, was
deine Aussage(n) fatalistisch macht:  Nur weil ich nicht sicher
sein kann, ob mein Messinstrument perfekt ist, soll ich nicht
messen dürfen!?  Damit erstickst du jede Wissenschaft in den
Kinderschuhen.  Bei der Lichtmikroskopie hat man auch gute Er-
gebnisse erzielt, bevor ihre Anwendung unterhalb des Abbe-Limits
ermöglicht wurde.  Und es ist auch nicht so, dass letztere die
vorher verfügbaren Messinstrumente obsoletiert.

Wenn ein grobes Luftbild vorliegt, handelt es sich doch längst
nicht um reine Raterei, sondern um Schätzung in Kombination mit
Erfahrungswerten, fehlerbehaftet gewiss, aber nicht unwissen-
schaftlich.  Wer sagt, das Wissenschaft stets fehlerfrei ist?
Wenn Daten mit Unsicherheit abgeleitet werden, geben Mapper bei
großer eigener Unsicherheit ja oft mit FIXME=was auch an, dass
die Genauigkeit der Erfassung in den mit Tag benannten Bereichen
klein ist.

Ja, Paper werden zurückgezogen.  Ja, FIXME=* Daten dürfen ver-
bessert werden.  Ja, "we map what's on the ground" _to best
possible effort_.  Der eine hat dabei mehr Ressourcen, der
nächste trägt mit weniger Mitteln bei.  So ist das auch in
der Wissenschaft, deren Betreiben jedem/jeder frei gestellt
ist.


Gruß

> On Mon, Oct 22, 2018 at 01:57:03PM +0200, Florian Lohoff wrote:
> 
> Aber dinge eintragen von denen ich nicht einmal gesichert sagen kann 
> ob sie wirklich existieren ist halt unwissenschaftlich. Das hat
> mit messen nichts zu tun sondern mit Raten und das sind dann die
> Paper die irgendwann zurückgezogen werden.
> 
> > Du hast recht, das schlechte Luftbilder sehr viel Raum für Fehl-
> > interpretationen liefern, aber das war in OSM noch nie Kriterium
> > dafür, gar nichts einzutragen.  Die Arbeitsweise ist eine, die
> 
> Doch - Das ist ein Kriterium. Das steht in den Best Mapping Practices.
> "We map whats on the ground" - Nicht mehr oder weniger. Etwas
> reinraten und als Entschuldigung schlechte Luftbilder angeben ist
> halt quatsch. Wie es Linus Torvalds mal sinngemäß gesagt hat: Ich kann
> pi in einer Sekunde bis zur 100sten Stelle berechnen solange
> das nicht richtig sein muss. 
> 
> Flo

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

Re: [Talk-de] Androhung von Benutzersperren für Verklebe-Ideologie

[Christian Müller]

Mit Fehler behaftete bzw. ungenaue Fakten sind nunmal auch Fakten,

Gemeint ist:  Wenn sich jemand 150,78 km/h fortbewegt, dann ist
eine Messung, die das mit Fehler +/- 10 km/h misst, ein Faktum,
genau so, wie jene, welche die Bewegung mit Fehler +/- 1 km/h
Toleranz misst.

Dazu analog ist m.E. die Problematik ungenau eingetragener Grenzen
im Datenbestand der OSM-DB.  Sie hängt wie genanntes Beispiel von
den verwendeten Messinstrumenten bzw. -methoden ab.


Gruß

> On Mon, Oct 22, 2018 at 08:27, "Florian Lohoff" wrote:
> 
> Ziehen des Landuses bis zum verkleben an die Straße ist IMMER falsch -
> 
> Flo

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

Re: [Talk-de] Androhung von Benutzersperren für Verklebe-Ideologie

[Christian Müller]

Mit Fehler behaftete bzw. ungenaue Fakten sind nunmal auch Fakten,
da kannst du dich noch so sehr bemühen, deine Definition derer als
die alleinige Wahrheit anzupreisen ;-).  Es gilt:
  "Wer misst, misst Mist."
und diese Ingenieursweisheit verschwindet auch im cm-Bereich nicht.

Du hast recht, das schlechte Luftbilder sehr viel Raum für Fehl-
interpretationen liefern, aber das war in OSM noch nie Kriterium
dafür, gar nichts einzutragen.  Die Arbeitsweise ist eine, die
inkrementell die Daten überarbeitet, je nach Kenntnisstand.  Das
wird auch dann so sein, wenn die hoch aufgelösten Luftbilder dem
Projekt ggf. nicht mehr zur Verfügung stehen.  Die Abweichung der
Geometrien zur Realität würde dann wieder größer, aber etwas,
das ungefähr die Realität wiedergibt, ist eben besser, als hoch-
präzise, aber inaktuelle Daten:

Das kannst du auch überall dort sehen, wo gebaut wird.  I.d.R.
erfolgt die Anpassung der Daten an eine präzisere Fassung erst,
wenn die Objekte später auf Luftbildern zu sehen und dann ab-
zeichenbar sind - die Erfassung findet aber oft weit vorher
statt und zu diesem Zeitpunkt ist es für OSM und viele seiner
Anwendungen oft egal, ob z.B. die Mittellinie einer neuen
Straße exakt an der geographisch korrekten Position liegt.


Die Diskussion um das Verkleben des Landuses hatten wir schon
und es ist sinnlos, die immer gleichen Argumente immer wieder
vorzutragen.  Das Hauptproblem ist, dass "falsch" und "rich-
tig" nur in einem Kontext benutzbar sind, in dem definitorisch
zunächst einmal genau geklärt ist, was wie im Datenmodell abge-
bildet wird.  Dieses Modell als Grundlage von OSM war und ist
aber nicht (komplett) interpretationsfrei.  Ein Großteil der
Diskussionen und Konsensfindungsbemühungen beschäftigt(e) sich
ja gerade damit, dieses Modell zu entwickeln.

Und so kann eben überall dort, wo es keine mathematisch exakte
Beschreibung der Features, aber stattdessen einen Spielraum
für Interpretation gibt, je nach Verständnis und ggf. auch
Anwendungsfall "richtig" sein, was nach anderem Verständnis
eben falsch ist.

In Gebieten, wo auf Luftbildern im Pixelbereich gerade so zu er-
kennen ist, dass eine Straße links und rechts von Acker gesäumt
wird, reicht die Information (Acker | Straße | Acker) für viele
Anwendungszwecke nunmal aus, egal wie gut oder schlecht/ungenau
die Landuse-Grenze in der DB repräsentiert wird und auch egal
ob sie verklebt ist, oder nicht.

Woher kommt eigentlich der Zwang, dieses Problem "per Dekret"
von oben herab lösen zu müssen?  Nach meiner Beobachtung löst
sich das Verkleben in Regionen mit gut aufgelösten Luftbildern
mittelfristig von selbst - denn dort konvergieren die einge-
tragenen Landuse-Grenzen gegen das, was auf dem Luftbild zu
erkennen ist.  Wenn Alt-Daten nicht mehr oder sehr schlecht
zum Status-Quo eines guten, aktuellen Luftbildes passen, dann
wird bei der Überarbeitung dieser Daten häufig intuitiv "ent-
klebt".  Und auch in solchen Fällen, in denen weiterhin ver-
klebt wird, rückt die Flächengrenze (etwa als Neueintrag) an
eine Position mit kleinerem Fehler (sofern die Georeferen-
zierung mitspielt).


Ein höher aufgelöstes Luftbild bringt aber i.d.R. andere
Probleme mit sich, denn die Auflösung bedingt auch eine ver-
änderte Wahrnehmung der Objekte mit sich.  Die Frage etwa
danach, was genau ein "Wohngebiet" ist und über welche Flä-
che es sich erstreckt (und auch ob Straßenflächen nun dazu
gehören oder nicht) wird bei einem niedrig aufgelösten Luft-
bild anders beantwortet, als wenn eines mit hoher Auflösung
betrachtet wird.

Überspitzt formuliert:  Falls ein Luftbild einzelne Grashalme
auflöst, stellt sich erneut die Frage, ob die ggf. von ihnen
geformte Wiese, die auf einer anderen Zoomstufe klar zusammen-
hängend erkennbar ist, nicht doch an der einen oder anderen
Stelle eine Diskontinuität aufweist und deshalb "richtig"-
erweise in separat gemappten Flächen erfasst werden sollte.

(Wenn bei Google automatisiert mit Laser-Ranging vermessen
wird, stellt sich die Frage nicht, denn die identifizieren
die Objekte (zunächst) nicht, sondern kümmern sich nur um
die Wiedergabe eine (gigantisch großen) Punktmenge, die so
ge-shaded wird, dass die Farbgebung der entspricht, die man
auch vor Ort wahrnehmen würde.  Was welches Objekt ist, liegt
dann im Auge des Betrachters.  Das bezieht sich nicht auf
die "normale" Google Maps Darstellung, sondern auf die Web-
GL Darstellung bei hoher Zoomstufe in fotorealistischem 3D.)


Das eine Objektgrenze von Baumkronen überlappt wird, bzw. durch
Schattenwurf verzerrt und suggestiv wiedergegeben wird, wenn
mit Luftbildern gearbeitet wird, mag sein.  Es ist in diesen
Fällen eine Frage der Übung bzw. der Erfahrung, wie gut diese
Bilder beim Ableiten von geographischen Features ausgewertet
werden (können).  Phrase dazu:
  "Es ist noch kein Meister vom Himmel gefallen."


Gruß

> On Mon, Oct 22, 2018 at 08:27, "Florian Lohoff" wrote:
> 
> Aeh ja - nein - Wenn dein Luftbild so schlecht ist das du das nicht
> erkennen kannst 

Re: [Talk-de] Androhung von Benutzersperren für Verklebe-Ideologie

[Christian Müller]

Prinzipiell +1, es ist aber auch eine Frage gegen (anhand) welche(r)
Auflösung gemappt wird.  Wenn Alleebäume, Graben und Bankette nicht
auf einem Luftbild zu erkennen sind und außerdem _keine_ Vorort-
Besichtigung stattfand, dann ist es _nach dieser Quellenlage_
nicht falsch, diese Objekte zu unterschlagen.

Eine ungenaue Ackergrenze ist in diesem Fall besser, als gar keine.
Sollen diese temporären bzw. groben Datenstände vermieden werden,
dann wäre eine Regel aufzustellen, nach der nur Daten in OSM einge-
tragen werden dürfen, die mit einem Fehler <= eps der Realität
entsprechen.  Solche eine Regel gibt es m.W. für/in OSM nicht.

Natürlich ließe sich mit ein paar Grund_annahmen_ über die Topologie
auch eine Ackergrenze _konstruieren_ die neben der Straße liegt, ob-
wohl kein genaues Luftbild zum Tracen vorliegt, aber das kann im
Zweifel die Realität genau so schlecht approximieren bzw. annähern,
wie das Verkleben, das in Gebieten mit schlechten oder gar keinen
Luftbildern nunmal einfach und bequem ist, selbst wenn ein Fehler
"eps" später bei geänderter Datenlage sichtbar wird.

Die Bewertung, ob etwas sachlich falsch ist, hängt also unmittel-
bar an der Verfügbarkeit entsprechender Information zum Abgleich.
Das ist der Wikipedia sehr ähnlich:  Oft als Tertiärquelle be-
nannt, kann die wiedergegebene Datenqualität nicht besser sein,
als das, was sekundärquellenhaft den Autoren (und auch den Ad-
mins ..) zur Verfügung stand.


In D ist das aufgrund sehr guter Auflösung der Orthofotos weniger
relevant, aber in anderen Gebieten sieht es eben anders aus. Selbst
wer einen Anschluss mit geringer Bandbreite hat, ist evtl. auch
hierzulande nicht bereit auf eine hochauflösende Orthofoto-Quelle
zurückzugreifen, obwohl sie zur Verfügung stünde.


Gruß


> On 21. Oct 2018, at 12:26, Florian Lohoff wrote:
>
> [..] Die mapper die dann kein "nichts" ertragen können ziehen dann das
> Farmland bis zur Straße und dann sind die Allebäume und der Graben und
> die Bankette teil des Ackers - und DAS ist sachlich falsch. [..]
> 
> 
> Flo

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

Re: [Talk-de] Androhung von Benutzersperren für Verklebe-Ideologie

[Christian Müller]

+1

Gruß

> On 20. Oct 2018, at 22:43, sepp1...@posteo.de wrote:
> 
> [..] Ob es nun Sinn macht, Straßenbelag als Fläche zu mappen, sei 
> mal dahin gestellt. Der Kompromiss könnte bspw. in einer 
> einvernehmlichen Festlegung oder besser Empfehlung bestehen, angrenzende 
> Flächen nicht zu verkleben, solange Straßenbelagfläche nicht gemappt 
> wurde, usw. usf. <= nur muss sowas irgendwo nachlesbar sein und zwar 
> nicht in einem Forenbeitrag von 2009 auf Seite 24, vorletzter 
> Seiteneintrag nach Bemühen einer Suchfunktion. [..]
> 
> Grüße
> Sepp

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

Re: [Talk-de] Grenzen und ihre Namen

[Christian Müller]

Diese Beobachtung habe ich auch schon gemacht:
Die Respektlosigkeit zu löschen, was andere
eingetragen haben, gehört zur Normalität ist
die Aussage?

Zur Sache:  Es gibt m.W. auch unbenannte Grenzen,
die einen Ersatznamen ("beschreibenden Namen") be-
kommen.  Für jene ist "Grenze" evtl. nicht Teil des
(Eigen-)Namens.  Diese beschreibenden Namen ließen
sich zudem algorithmisch ableiten, wenn der Weg,
der in OSM die Grenzlinie repräsentiert, jeweils
Teil der MPs ist, welche die begrenzten Flächen
repräsentieren.

Häufig werden die Linien auch benannt, um sowohl
beim Mappen als auch auf einer gerenderten Karte
einfacher den Überblick zu behalten


Gruß

> Gesendet: Samstag, 13. Oktober 2018 um 23:45 Uhr
> Von: "Martin Scholtes" 
> An: "OSM-Maillingliste Talk-DE" 
> Betreff: Re: [Talk-de] Grenzen und ihre Namen
>
> Das hat nichts mit Respektlosigkeit zu tun. Es ist normal, das der eine
> etwas einträgt und nach einer Gewissen Zeit ein andere es wieder löscht.
> Ich halte es nur für sinnlos eine Grenze zu benennen, nur weil man damit
> ausdrücken möchte was hier begrenzt wird. Zudem wurde scheinbar diese
> Benennung nur einseitig vorgenommen. Was würde den für eine Benennung
> von Grenzverläufe sprechen?
> 
> Am 13.10.2018 um 23:38 schrieb Martin Koppenhoefer:
> >
> > sent from a phone
> >
> >> On 13. Oct 2018, at 23:30, Martin Scholtes 
> >> wrote:
> >>
> >> Somit kann ich ja getrost die Way´s bereinigen, bzw hab es so eben getan.
> >
> > Völlig unnötige Respektlosigkeit. Etwas nicht einzutragen ist ein
> > Ding, zu löschen was andere eingetragen haben ein anderes.
> >
> > Gruß, Martin ___
> > 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

[Christian Müller]

> Gesendet: Sonntag, 22. April 2018 um 08:20 Uhr
> Von: mmd 
> 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

[Christian Müller]

> Gesendet: Samstag, 21. April 2018 um 23:20 Uhr
> Von: "Martin Koppenhoefer" 
> An: "Openstreetmap allgemeines in Deutsch" 
> 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

[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" 
> An: "Openstreetmap allgemeines in Deutsch" 
> 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

[Christian Müller]

> Gesendet: Donnerstag, 19. April 2018 um 21:41 Uhr
> Von: mmd 
> 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

[Christian Müller]

> Gesendet: Donnerstag, 19. April 2018 um 14:49 Uhr
> Von: "Martin Koppenhoefer" 
> An: "Openstreetmap allgemeines in Deutsch" 
> 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" 
> An: "Openstreetmap allgemeines in Deutsch" 
> 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

[Christian Müller]

> Gesendet: Mittwoch, 18. April 2018 um 23:26 Uhr
> Von: "Michael Reichert" 
> An: "Openstreetmap allgemeines in Deutsch" 
> 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" 
> 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

[Christian Müller]

> Gesendet: Sonntag, 08. April 2018 um 22:40 Uhr
> Von: "Martin Koppenhoefer" 
> An: "Openstreetmap allgemeines in Deutsch" 
> 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

[Christian Müller]

> Gesendet: Sonntag, 08. April 2018 um 22:21 Uhr
> Von: "Martin Koppenhoefer" 
> An: "Openstreetmap allgemeines in Deutsch" 
> 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

[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

[Christian Müller]

> Gesendet: Sonntag, 08. April 2018 um 09:56 Uhr
> Von: "Falk Zscheile" 
> An: "Openstreetmap allgemeines in Deutsch" 
> 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

[Christian Müller]

> Gesendet: Sonntag, 08. April 2018 um 00:17 Uhr
> Von: "Martin Koppenhoefer" 
> An: "Openstreetmap allgemeines in Deutsch" 
> 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

[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

[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 
> 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
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 

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

[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

[Christian Müller]

> Sent: Wed, 4 Apr 2018 16:39:05 +0200 
> From: "Martin Koppenhoefer" 
> To: "Openstreetmap allgemeines in Deutsch" 
> 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" 
> 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 falsch,
das Datenmodell an der Unerfahrenheit auszurichten, so dass es dann
nicht mehr adäquat die Situation vor Ort / am Boden repräsentiert.

Ich bin Vereinfachungen gegenüber 

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" 
> To: Markus 
> 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" 
> To: "Frederik Ramm" 
> 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 großer Mist, weil fehlerbehaftet.
Es entspricht quick-and-dirty Methoden, die man benutzt, wenn man

Re: [Talk-de] Mitteldeutsche Schleife -> reg_name ?

[Christian Müller]

> Gesendet: Mittwoch, 07. September 2016 um 09:22 Uhr
> Von: "Florian Lohoff" <f...@zz.de>
> An: "Christian Müller" <cmu...@gmx.de>
> Cc: talk-de@openstreetmap.org
> Betreff: Re: [Talk-de] Mitteldeutsche Schleife -> reg_name ?
>
> On Wed, Sep 07, 2016 at 06:01:57AM +0200, Christian Müller wrote:
> > >Der name= tag sollte das beinhalten was auch beschildert ist. Was dann
> > >in loc_name=, reg_name= noch so drin steht ist dann ja relativ egal.
> > >Das hilft dann beim wiederfinden via Nominatim aber verwirrt nicht.
> > 
> > Dann viel Spaß beim Aufräumen in OSM.
> 
> Das ist dein Argument?

Das war _eines_ meiner Argumente, ja.
Sicherlich kein Hauptargument, aber
wenn du dich daran aufhängen willst,
bitte.

Die Diskussion entfernt sich allmählich
von ihren sachlichen Grundlagen, deshalb
ist für mich jetzt hier Schluss.  Das
wesentliche zum Thema ist gesagt, wie
immer darf jeder seine eigene Meinung
und Sicht darauf haben und die Zeit
wird zeigen, was übrig bleibt.


Gruß
Christian

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

Re: [Talk-de] Mitteldeutsche Schleife -> reg_name ?

[Christian Müller]

Am 6. September 2016 22:37:13 MESZ, schrieb Florian Lohoff <f...@zz.de>:
>On Tue, Sep 06, 2016 at 06:09:32PM +0200, "Christian Müller" wrote:
>> b) Mit regionalen Namen verhält sich das auf fraktale Weise genauso,
>> du musst nur ein bisschen "reinzoomen".  Sie wirken auf dich befremd-
>> lich, weil du nicht aus der Region stammst.  Doch ist es gerade die
>> Region (der Landstrich, das Dort, die Stadt, der Ort), die einen
>> allgemeinen Namen häufigst bestimmt und diesen dann hinausträgt!?
>
>Der name= tag sollte das beinhalten was auch beschildert ist. Was dann
>in loc_name=, reg_name= noch so drin steht ist dann ja relativ egal.
>Das hilft dann beim wiederfinden via Nominatim aber verwirrt nicht.

Dann viel Spaß beim Aufräumen in OSM.

Bzgl. der Routing-Anweisungen hast du meine Ausführungen zu ref=
vs. name= gekonnt überlesen.

Außerdem ist name= nicht ausschließlich für Routinganwendungen
da, hier solltet ihr etwas generischer denken als einen Anwendungsfall
im Tunnelblick zu bearbeiten.

AVUS
Autobahn der Freiheit
Östlicher Berliner Ring
Berliner Ring
..

sind evtl. vor Ort auch nicht beschildert, aber im allg. Sprachgebrauch
und im Behördendeutsch etablierte Bezeichnungen.  Mehr Bedarf es
für die Erfassung als name= nicht,  aber ihr könnt freilich auch ne
Extrawurst daraus machen...  ..wäre ja auch nicht das erste Mal in
OSM.


Gruß
Christian


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

Re: [Talk-de] Mitteldeutsche Schleife -> reg_name ?

[Christian Müller]

> Gesendet: Dienstag, 06. September 2016 um 00:41 Uhr
> Von: "Tom Pfeifer" 
> An: "Openstreetmap allgemeines in Deutsch" 
> Betreff: Re: [Talk-de] Mitteldeutsche Schleife -> reg_name ?
>
> auf den Einzelautobahnen finde ich es irritierend.

Hier ist noch eine Bezeichnung, die dich evtl. irritiert:
http://www.openstreetmap.org/#map=15/52.3157/13.7972

"Autobahn der Freiheit"

Ganz ehrlich:  Habe ich noch nie gehört!  Trotzdem
käme ich wohl nicht auf die Idee, dieses Nomen den
Berlinern streitig zu machen.

Diskutieren ließe sich auch über die zusammenge-
setzen Ortsbezeichnungen auf dem "Berliner Ring"

"Östlicher Berliner Ring"
"Südlicher Berliner Ring"
..

sind zusammengesetzte Lagebezeichnungen, das als
"name" zu verwenden finde ich eher irritierend.

Da könnte ebenso gut jeder Innenstadtring in vier
(oder mehr) Teile untergliedert und separat be-
namt werden.  Dennoch sehe ich hier keinen Änder-
ungsbedarf:  Schonmal probiert Berlinern vorzu-
schreiben, wie sie zu quatschen haben? :)


Gruß
Christian

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

Re: [Talk-de] Mitteldeutsche Schleife -> reg_name ?

[Christian Müller]

> Gesendet: Dienstag, 06. September 2016 um 00:41 Uhr
> Von: "Tom Pfeifer" 
> An: "Openstreetmap allgemeines in Deutsch" 
> Betreff: Re: [Talk-de] Mitteldeutsche Schleife -> reg_name ?
>
> > Da schieben wir doch am besten gleich die regionalen
> > Bezeichnungen in anderen Ländern ebenfalls in reg_name
> > und schreiben brav die deutschen Namen als die allgemein
> > Benutzten hinein.  Klar, das wir dazu allgemein deutsche
> > Quellen anführen und die regional fremdländischen brav
> > ignorieren.
> 
> Der Ironie kann ich aber nur bedingt folgen. Für deutschsprachige Namen
> im Ausland gibt es name:de, darum geht es hier nicht.

Du hast leider nicht verstanden, was ich damit zum Ausdruck bringen
wollte.  Es ist nicht nur Ironie, sondern es ist das gleiche in grün,
nur eine Ebene nach oben gehoben.  Also nochmal in Klartext:

a) name im Ausland nutzt den dort typischen, allgemeinen Namen, der
auf uns durchaus wie ein regional benutzter Name wirken kann, gerade
wenn historisch, aus Besatzerzeit oder Vorkriegsjahren noch dt. Namen
bestehen, die im Sprachgebrauch einer dt. Allgemeinheit noch vorhanden
sind

b) Mit regionalen Namen verhält sich das auf fraktale Weise genauso,
du musst nur ein bisschen "reinzoomen".  Sie wirken auf dich befremd-
lich, weil du nicht aus der Region stammst.  Doch ist es gerade die
Region (der Landstrich, das Dort, die Stadt, der Ort), die einen
allgemeinen Namen häufigst bestimmt und diesen dann hinausträgt!?

Es gibt sicherlich Beispiele, wo das nicht funktioniert.  Für diese
gilt dann tatsächlich reg_name != name, aber die Regel ist
reg_name == name  (insbes. wenn Fälle, in denen reg_name als
Feld für Spitz- oder Kosenamen ohne offiziellen Charakter un-
beachtet bleiben).


> Vielmehr wollte ich sondieren, ob die Bezeichnung, wenn sie schon
> nicht ausgeschildert wurde, wenigstens allgemeiner Sprachgebrauch ist.

Wenn du eine Beschwerde an die zuständigen Ämter schickst,
wirst du dein Schild möglicherweise bekommen.  Da werden
die sich nicht Lumpen lassen.


> Die von dir zitierten Dokumente stützen aber eher das Gegenteil,
> es erscheint als eine Meinung eines ehemaligen Verkehrsministers und eine
> Radio-PR-Aktion, alles im Jahre 2003, und gelegentlich taucht die
> Bezeichnung noch in Gänsefüsschen in politischen Dokumenten zum
> Weiterbau der A143 auf.

Es taucht in mehreren Büchern und Dokumenten auf.  Der Begriff ist eben
nicht "Meinung eines ehemaligen Verkehrsminister", sondern wurde aus
Vorschlägen der Bevölkerung ausgewählt.  Vielleicht ist die Auswahl an
sich Meinung des Ministeriums (nicht des Ministers und definitiv nicht
der Begriff!).


> Der Berliner Fernsehturm sollte auch mal unbedingt "Telespargel" genannt
> werden, sagte und sagt aber keiner.

Es gibt sicher nicht wenige, die dennoch wissen, was du meinst.
Ich mutmaße, dass dieser Begriff nicht Ergebnis einer offiziellen
Namenssuche war.


> Also machen wir die Gegenprobe:
> 
> - Wenn du jemand von Grimma nach Löbejün zum Klettern lotst, empfiehlst
>du ihm "Nimm die Nördliche Mitteldeutsche Schleife" oder "Fahr die A14"?

Ich würde ihn "Löbejün" in sein Navi tippen lassen.
Spaß beiseite:  Das ist natürlich auszuhandeln.  Wenn er mit der Schleife
etwas anfangen kann, warum soll ich mich dann fälschlicherweise auf die
A14 in voller Länge beziehen?

Das ist beides nicht falsch.  Ein Abschnitt der A14 ist Teil der Mittel-
deutschen Schleife, per Definition.


> - Möchtest du, dass dir dein Navi am Schkeuditzer Kreuz empfiehlt,
>"Biege jetzt ab auf die Mitteldeutsche Schleife"? Wohin fährst du dann?

Navi Anweisungen enthalten neben dem Namen des Ziels i.d.R. Richtungs-
anweisungen.  Die Frage stellt sich schon aus diesem Grund nicht.

Außerdem wertet das Navi für hochrangige Straßen doch eher ref aus?
Und in ref steht hoffentlich A 14 / A 38 / etc..

Wenn Bundesstraßen ortsbezogene Namen besitzen, kannst du mit denen
auch nichts anfangen, wenn du lediglich die Anweisung hören willst,
der Bundesstraße B xx weiter zu folgen.


> Mangels Fertigstellung der A143 ist die Schleife ja noch nicht mal eine.

Das ist Ansichtssache.  Es ist ja nun nicht so, dass du dein Auto da nicht
auf einer niedrigrangigeren Straße von Süd nach Nord durchschieben könntest.


> Mit einer Routenrelation könnte ich mich ja noch anfreunden, aber
> auf den Einzelautobahnen finde ich es irritierend.

Ich finde das nicht irritierend.  Hier hat eine Koproduktion
von Amt und Bürger gewählt und dieser Name erscheint auf einer
urdemokratischen Karte: OSM.  Alles hübsch also.


Gruß
Christian

ps: Gäbe es einen "richtigeren" Namen, wäre "Mitteldeutsche Schleife"
aufgrund der Quellenlage nicht nach "reg_name" sondern wohl eher nach
"alt_name" zu verschieben.  Das ist aber ein irrelevanter Konjunktiv.

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

Re: [Talk-de] Mitteldeutsche Schleife -> reg_name ?

[Christian Müller]

> Gesendet: Montag, 05. September 2016 um 20:03 Uhr
> Von: "Tom Pfeifer" 
> An: "Openstreetmap allgemeines in Deutsch" 
> Betreff: [Talk-de] Mitteldeutsche Schleife -> reg_name ?
>
> Laut Wikipedia [1] entstand dieser Name als Hörer-Wettbewerb eines
> Radiosenders.

Das ist im Übrigen nur die halbe Wahrheit, der Wettbewerb wurde von
MDR Info _und_ den Verkehrsministerien der Länder Sachsen und Sachsen-
Anhalt durchgeführt.  Das war laut MZ im Jahr 2003:

Quelle(n):
http://www.mz-web.de/mitteldeutschland/-mitteldeutsche-schleife--autobahnring-halle-leipzig-erhaelt-namen-10071178
http://www.mz-web.de/nachrichten/verkehr-autobahnringe-werden--mitteldeutsche-schleife--9968710


Da der Verkehrsfunk i.d.R. lokal funkt ist und m.W. nicht schrift-
lich festgehalten wird, ist es nicht ratsam ihn als Quelle gegen
oder für ein Lemma heranzuziehen.  Ein "allgemeiner Name" lässt
sich mit seiner Hilfe weder nachweisen noch widerlegen.


Gruß
Christian

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

Re: [Talk-de] Mitteldeutsche Schleife -> reg_name ?

[Christian Müller]

> Gesendet: Montag, 05. September 2016 um 20:03 Uhr
> Von: "Tom Pfeifer" 
> An: "Openstreetmap allgemeines in Deutsch" 
> Betreff: [Talk-de] Mitteldeutsche Schleife -> reg_name ?
>
> Daher plädiere ich dafür, das Tagging mit dieser Bezeichnung in
> reg_name oder loc_name [4] zu überführen, da ich es für einen
> regional und nicht allgemein genutzten Namen halte.

Da schieben wir doch am besten gleich die regionalen
Bezeichnungen in anderen Ländern ebenfalls in reg_name
und schreiben brav die deutschen Namen als die allgemein
Benutzten hinein.  Klar, das wir dazu allgemein deutsche
Quellen anführen und die regional fremdländischen brav
ignorieren.  

[1] 
https://books.google.de/books?id=1VMLAQAAMAAJ=mitteldeutsche+schleife=mitteldeutsche+schleife=de=X_esc=y

[2] 
http://www.asp.sachsen-anhalt.de/presseapp/data/mwv/2010/019_2010_6331969d0001fc12e34dc7070cdd54fa.htm

[3] 
http://www.mlv.sachsen-anhalt.de/fileadmin/Bibliothek/Politik_und_Verwaltung/MLV/MLV/GesetzeVWVO/OEPNV/OePNV-Plan-Sachsen-Anhalt_2010-2015-25_final.pdf
  (Seite 21 (19))

[4] http://mobile.sachsen-anhalt.de/APP2308/content/2321.php

..


Gruß
Christian

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

Re: [Talk-de] Live-Map ÖPNV für Ulm/Neu-Ulm

[Christian Müller]

> Gesendet: Samstag, 27. August 2016 um 17:48 Uhr
> 
> Beim VBB (Verkehrsverbund Berlin-Brandenburg) gips das noch:
> 

Ok, wer lesen kann ist klar im Vorteil:

VBB-Livekarte zeigt berechnete Positionen der Fahrzeuge zwischen zwei Stationen;
falls kein Live-Fahrplan vorhanden, dann Position gemäß geplanten Fahrzeiten

Position der Fahrzeuge ist nicht metergenau


Vermutlich kommt statt GPS ein Kontrollsystem für die Vehikel
an den Haltestellen zum Einsatz?  Die Soll-Zeit bis zur nächsten
Haltestelle ist jeweils bekannt, daraus werden dann Verpätung und
aktuelle Position auf der Route berechnet?  Klappt natürlich nur
solange der VBB die Kontrollpunktdaten veröffentlicht, oder darauf
basierende, verarbeitete Daten.


Gruß
Christian

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

Re: [Talk-de] Live-Map ÖPNV für Ulm/Neu-Ulm

[Christian Müller]

> Gesendet: Samstag, 27. August 2016 um 19:39 Uhr
> 
> Kennst du TRAVIC (http://tracker.geops.ch/?z=6=1=1242914.2612=663
> 2341.6975=transport)? Dargestellt werden die Soll-Positionen auf
> Basis der Fahrplandaten. In Deutschland ist die Abdeckung relativ hoch,
> praktisch alles, was in der DB-Auskunft erscheint, wird auch auf der
> Karte dargestellt. Live-Daten gibt es aktuell leider nur in einigen
> Regionen außerhalb Deutschlands.

@Alexander: Danke für den Link, kannte ich noch nicht.


@Streckensucher:  Danke für den VBB-Hinweis.  Sind das wirklich Live-
Daten im VBB?  Imho deuten die angegebenen Verzögerungen darauf hin,
womit deren Karte sowohl gegenüber Ulm (Dank an Jochen) und ggü TRAVIC
noch ein Stück näher an der Realität ist:

Für Menschen, die auf ÖPNV angewiesen sind, aber an Haltestellen ggf.
demolierte Anzeigetafeln vorfinden, ist eine Angabe der Fahrplanver-
zögerungen evtl. schon relevant (insbes. wenn t>5 min).


@Jochen:  Vielen Dank für http://live.ulmapi.de/map - ist das eine
Parallelentwicklung oder ein Nachfolger der vom Blog in 2011 bewor-
benen Karte?  Kann man den Artikel im Blog evtl. aktualisieren oder
kommentieren?  Ich finde es immer ärgerlich, wenn Links ohne Redirect
verschwinden, gerade dann, wenn die eigentlichen Inhalte doch irgend-
wo weiterbetrieben werden.


Gruß
Christian

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

[Talk-de] Live-Map ÖPNV für Ulm/Neu-Ulm

[Christian Müller]

Hallo Gemeinde,


in 2011 gab es einmal eine Live-Map, welche den Ist-Stand des ÖPNV-Verkehrs in 
ULM auf einer Openstreetmap-Karte darstellte.  Das war sogar eine Meldung im 
dt. OSM-Blog wert:

http://blog.openstreetmap.de/blog/2011/09/wochennotiz-nr-59/#karten_

Wurde diese Errungenschaft eingestampft, migriert oder weggespart?  Weiß jemand 
Näheres?

Gibt es überhaupt noch derartige Live-Maps in anderen dt. Gemeinden / für 
andere Verkehrsverbünde?  Oder hat man sich mit dem Verweis auf Bedrohungslagen 
und der Behauptung, das verunsichere Teile der Bevölkerung, davon generell im 
OSM-Univerum distanziert?

Der ursprüngliche Link zur Live-Map in Ulm jedenfalls ist tot:
http://ulmapi-de.no.de/map


Grüße,
Christian

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

[Talk-de] Info - zki.dlr.de benutzt OSM Daten

[Christian Müller]

Hi,


soweit ich weiß ist das noch nicht auf der Liste gewesen.  Anlässlich
des Hochwassers stellt das Zentrum für Satellitengestützte
Kriseninformation (ZKI) Übersichtskarten mit den Überflutungsflächen
bereit, siehe

http://www.zki.dlr.de/de/article/2374

Die Karten sind ein Mash-Up aus OSM-Daten und anderen Kartenquellen. 
Sie werden mit (c) OpenStreetMap-Mitwirkende attributiert (rechts unten
in den Lagebildern).  Die Karten sind auch in

   
https://de.wikipedia.org/w/index.php?title=Hochwasser_in_Mitteleuropa_2013#Weblinks

verlinkt.


MfG
Christian

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

Re: [Talk-de] Nachtrag Bing Luftbildzensur

[Christian Müller]

Am 18.07.2012 18:58, schrieb Stephan Wolff:
 da die neue Luftbildzensur von Bing auch diverse zivile Gebiete
 betrifft, habe ich bei der Bundeswehr nachgefragt, ob sie dies
 veranlasst hat.
 []
 Sehr geehrter Herr Wolff,
 []
 Warum Bing auch das Gewerbegebiet Friedrichsort und den Strand
 verschleiert hat, entzieht sich unserer Kenntnis. Dies ist durch die
 Bundeswehr nicht veranlasst worden. Wir können daher diese Maßnahme
 nicht rückgängig machen.
 []
 Grundsätzlich beziehen sich die durch die Bundeswehr veranlassten
 Schummerungen [Weichzeichnung] nur auf Liegenschaften und
 Sperrgebiete (z.B. Übungsplätze). Die Bundeswehr kann und darf keine
 weitergehenden Schummerungen veranlassen.
 []

Hi,

der Schaden, den sich Bing nach Antrag der Weichzeichnung durch Behörden
unbekannt selbst zugefügt hat, wurde bisher nicht auf das ursprünglich
durch diese Behörden geforderte (und nach Behördenaussagen rechtlich
erlaubte) Minimum begrenzt.

Wissen Mitleser dieser Liste mehr über diese Aktion, als letztes Jahr?
Wurde geklärt, wer die Weichzeichnungen beantragte und auf welcher
Grundlage?

Sind die Behörden evtl. verpflichtet ihre Anfragen über Weichzeichnungen
an Bing zu veröffentlichen?

Gibt es eine Liste solcher Anfragen anhand derer nachprüfbar wäre, ob
Bing der Anfrage
  - entsprochen, d.h. nicht mehr oder weniger verpixelt hat, als angefragt?
  - über- oder untererfüllend entsprochen, d.h. mehr oder weniger
verpixelt hat, als gefordert?


Listenmitglieder haben damals anhand der Grenzen der Weichzeichnung
abgeleitet, dass von Bing OSM-Daten mit Stand 2010 verwendet wurden, um
den Anfragen zu entsprechen.  Vielerorts waren diese Daten fehlerhaft,
d.h. best guesses der Mapper vor Ort.  Das führte dazu, dass teilweise
historische oder angrenzend zivile Gebiete, für welche rechtlich keine
Antragsgrundlage existiert, von Bing verpixelt wurden.


Mittlerweile ist diese Datengrundlage überholt.  In drei Jahren Arbeit
hat sich in OSM die Genauigkeit der Flächengrenzen verbessert.  Wenn
Bing schon anhand OSM-Daten rät, welche Gebiete einer behördlichen
Amtsanfrage weichzuzeichnen sind:

1) Macht es evtl. Sinn, Bing nach einer Aktualisierung der
Weichzeichnungsgrenzen mittels aktueller(er) OSM-Daten zu fragen?

Würde Bing auf eine Behördenanfrage hin Geodaten (Polygone statt
Straßenadressen) von selbiger anfordern, anstatt OSM-Daten zu verwenden,
wäre das zweifelsohne besser.  Die Bundeswehr hat uns mitgeteilt, dass
sie nur Weichzeichnungen ihrer Liegenschaften und Sperrgebiete
beantragen darf:

2) Reicht es dann rechtlich gesehen überhaupt aus, wenn dem Dienst Bing
durch die dt. Behörde lediglich Straßenadressen übergeben werden?  Ist
sie nicht evtl. sogar verpflichtet, exakte Gebietsgrenzen/Polygone in
ihrer Anfrage zu übermitteln?


Mich stört aktuell die verwendete Grenze für

  Friedenstein-Kaserne, Ohrdrufer Straße, Gotha

  - die Bing-Weichzeichnung ist etwa doppelt so groß, wie das
eigentliche Gebiet der Kaserne (Stand 2010?)
  - die Flächengrenze für das militärisch genutzte Gebiet entspricht der
in OSM erfassten (aktueller Stand)
- http://www.openstreetmap.org/browse/way/187241008  (leider ohne
Chronik, redaction bot?)

  - in Google Maps wird weder die Kaserne, noch das angrenzende
Gewerbegebiet verpixelt

  - ein weiteres Polygon wurde östlich hinzugefügt, das bisher nicht
verpixelt wird
  - südlich ist das aktuelle Polygon eines Übungsplatzes wesentlich
größer als die überlappende Verpixelung, welche ebenfalls großflächig
zivil genutztes Gebiet überdeckt
- Mutmaßung:  Luftbildinformationen bleiben für Bing-Nutzer
offener, wenn 2) vorrangig 1) behandelt wird

Angesichts der andauernden Verfügbarkeit der Bilder in Google Maps,
stellt sich also weiter die Frage:
  Weshalb stellt die Behörde unbekannt ihre Anfragen nur an Bing/MS?

Falls auch Anfragen an Google gestellt wurden:
  Wieso fällt deren Reaktion anders aus, als die von Bing?


Die unterschiedliche Verpixelungspraxis bei Bing/Google verstehe wer will.
Wenn weichgezeichnet wird, dann aber bitte nur das, was muss.


Grüße
Christian

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

Re: [Talk-de] Nachtrag Bing Luftbildzensur

[Christian Müller]

Am 18.07.2012 18:58, schrieb Stephan Wolff:
 da die neue Luftbildzensur von Bing auch diverse zivile Gebiete
 betrifft, habe ich bei der Bundeswehr nachgefragt, ob sie dies
 veranlasst hat.

Zusatz zur letzten mail:  Die Weichzeichnung scheint weltweit zu gelten.
 Selbst unter Nutzung eines US-Webproxies werden die Gebiete verpixelt.
 Kann das jemand bestätigen?

Grüße
Christian

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

Re: [Talk-de] Nachtrag Bing Luftbildzensur

[Christian Müller]

Am 08.05.2013 23:11, schrieb Martin Simon:
 Am 8. Mai 2013 22:24 schrieb Martin Koppenhoefer dieterdre...@gmail.com:
 Sind denn immer noch Reste dieser alten OSM-Daten in den aktuellen
 Luftbildern?
 Wenn ich mir das Bonner Verteidigungsministerium ansehe: nein.
 Und ich hätte lieber die alten Daten zurück: hier wurde in Ermangelung
 genauerer Daten besonders großzügig verpixelt (sicher ist sicher), so dass
 die Terroristen jetzt auch Den benachbarten Park, Die Tennisanlage, Das
 Freibad, den Kletterwald, den Kindergarten, die Umspannstation, das
 Heizkraftwerk und die Schießsportanlage nebst Biergarten nicht mehr
 angreifen können.
 Danke, ich fühl' mich gleich viel sicherer.

;-) ..  Wie gesagt, nach der Info die Steffen von den Tarnfleckleuten
bekommen hat, darf dieser Verpixelungsgrad rechtlich nicht beantragt
werden.  Das Problem scheint wohl eher Bing zu sein, wenn sie
behördliche Anfragen übererfüllen.  Google zeigt doch, dass es auch
anders geht.

Ernsthaft, fällt euch nix ein, was sich da tun ließe?
Gibt es denn niemanden, den wir mit unseren Anfragen belästigen können?


Grüße
Christian

ps:  Du hast noch Flugzeug als keyword vergessen.

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

Re: [Talk-de] Stadtteilfuckup in Nominatim

[Christian Müller]

Am 09.05.2013 00:55, schrieb Ruben Kelevra:
 Nun, wie ich bereits sagte nimmt Nominatim den Stadtteil außerhalb des
 Stadtgebiets der definitiv NICHT zu einer Straße im Stadtgebiet
 gehört. Ich wüsste aber nicht wie ich den Stadtkern selbst taggen
 soll. Das ist das primäre Problem.

 Hat jemand dafür einen Vorschlag?

Vorschlag:  Schaue Dir die administrativen Stadt-/Ortsteilgrenzen von
anderen Städten, wie z.B. Berlin oder Hamburg an.

Zweiter Vorschlag:  Wenn das Stadtgebiet als Fläche (Multipolygon o.ä.)
erfasst ist, Nominatim aber für Objekte innerhalb dieses Gebiets Namen
außenliegender OSM-IDs verwendet, dann sind letztere zu prüfen:

  Handelt es sich um einen Node, prüfe ob er in der place=* Hierachie
genügend weit unten steht, so dass der Default-Perimeter, den
Nominatim zur Verschneidung verwendet, nicht mehr das Stadtgebiet überdeckt

  Handelt es sich um eine Fläche, stelle sicher, dass die Basisgeometrie
keine Validierungsfehler hat und sie nicht andere Grenzen gleichen Typs
schneidet.  Nicht alle Fehler werden dabei durch den Validator entdeckt.

So oder so ähnlich.  Ich erinnere mich an die Ausbesserung eines nodes,
der als place=region getaggt war.  Es ging dem Eintragenden nur darum,
dass die Bezeichnung für den Landstrich an der Stelle in der Karte
erschien.  Nach Wiki-Definition wäre der node auch nicht mit
place=region auszuzeichnen gewesen.  Ich habe ihn schließlich auf
place=locality herabgestuft.  Vor dieser Herabstufung erschien der Name
dieses Nodes im Umkreis von etwa 100km innerhalb Nominatim für fast alle
Objekte, denen keine anderes, umkreisnäheres place=region Objekt
Konkurrenz machte.

Ich hoffe, Du findest einen Weg und kannst den Fehler ausbügeln.


Gruß
Christian

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

Re: [Talk-de] Zu viel gelöscht?

[Christian Müller]

Am 07.08.2012 21:24, schrieb Andreas Tille:
 Bevor ich das jetzt wieder geradeziehe die Frage:  Wurde hier eventuell zu 
 viel
 gelöscht?

Wichtiger wäre, erst einmal zu klären, wie lange die ODbL dem Projekt
nun genügt.  Wenn übernächstes Jahr der nächste Wechsel bevorstellt,
weil irgendjemand e.g. rechtliche Lücken in der ODbL entdeckt, frißt
sich der nächste Pacbot durch die mit Mühe recherchierten Daten.  Der
Schaden ist m.E. deshalb so beträchtlich, weil bis auf den OSMI, der
schlecht in Editoren integriert ist, überhaupt keine Möglichkeit
besteht, zu ermitteln, was überhaupt gelöscht wurde.

An den Geometrien, welche der destruction_bot (tm) nicht vernichtet hat,
lässt sich zwar ein Stückchen History ermitteln, aber um die ganzen
zerfetzten Nodes zuzuordnen, die links und rechts teilzerstörter Wege
liegen, hilft selbst die herzlich wenig.  Übrig bleibt die Hoffnung,
dass verbliebene Mapper genug Nerven haben, das wieder aufzuhübschen..

Ein wichtiges Motto von OSM hat der bot jedenfalls superb unterstützt: 
Spaß haben..


LG
Christian

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

Re: [Talk-de] Zu viel gelöscht?

[Christian Müller]

Am 07.08.2012 22:01, schrieb Frederik Ramm:
 Hallo,

 On 07.08.2012 21:47, Christian Müller wrote:
 weil bis auf den OSMI, der
 schlecht in Editoren integriert ist, überhaupt keine Möglichkeit
 besteht, zu ermitteln, was überhaupt gelöscht wurde.

 Also perfekt ist das sicher nicht mit dem OSMI, aber dass Du
 OSMI-Layer sowohl in JOSM als auch in Potlatch als Hintergrund
 anzeigen lassen kannst, ist Dir bewusst?

Nope.  Where do I have to dig?

Thanks.
Christian

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

Re: [Talk-de] Karte für Windkraftanlagen - meinst Du soetwas?

[Christian Müller]

Am 20.07.2012 18:13, schrieb Bernhard Weiskopf:
 Wobei hier viele Kraftwerke fehlen. 

 Vermutlich sind nur Punkte (nodes) abgefragt, ..

Ein Problem dürften die verwendeten Filter sein, das KW Lippendorf z.B.
ist folgendermaßen getaggt:

Punkt: Kraftwerk Lippendorf (253731394)
generator:method=combustion
name=Kraftwerk Lippendorf
power=generator
generator:output:electricity=1867.2 MW
generator:output:heat=330 MW
generator:output=cogeneration
operator=Vattenfall Europe Generation AG
generator:source=coal


Jan verwendet aber einen underscore lt. website, ansonsten feine Sache -
danke.


lg
Christian

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

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

[Christian Müller]

Am 18.07.2012 20:24, schrieb Tobias Knerr:
Die Lösung mit dem Wikipedia-Tag hingegen funktioniert heute bereits 
gut. Es genügt zwar nicht, wenn es z.B. um Karten in Sammelartikeln 
für mehrere geografische Objekte geht, die selbst keinen eigenen 
Artikel bekommen. Diesen Anspruch erhebt es meines Wissens aber auch 
nicht.


+1

Ich finde die Debatte, ob das nun ein Fremdschlüssel ist und welche von 
beiden Infosammlungen, die wichtigere sei, völlig übertrieben.  Eine 
Auswertung durch WIWOSM ändert für mich auch nicht die Linkrichtung, es 
bleibt weiterhin eine schwache Referenz von OSM zu WP.  Zudem wäre eine 
Umsiedlung des wikipedia-Tags weit weniger projektfreundlich als es der 
Zuzug von WIWOSM war, der imho minimalinvasiv geschah.


Eine Lösung zu schreiben, die beim Verschieben eines Lemmas in der WP 
das zugehörige wikipedia-Tag in OSM ändert, oder wenigstens den Nutzer 
warnt, ist weit einfacher umzusetzen, als das Tag umzusiedeln und 
sämtliche Software zu brechen, die mittlerweile darauf aufbaut.



Gruß
Christian

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

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

[Christian Müller]

Sarah Hoffmann lon...@denofr.de schrieb:

On Tue, Jul 17, 2012 at 02:11:37AM +0200, Stephan Wolff wrote:
 Wozu
 also die Relation? Nur fuer die fiktive Frage wie viele Strassen hat
 die Stadt?
 Für alle Fragen, die Straßen (im üblichen Sinn) betreffen:
 - Suche: Wo ist die ...straße? - Aktuell liefert Nominatim zu einer
  langen Straße oft mehrere Dutzend Treffer von OSM ways.
 Wenn Nominatim das entsprechend zusammenfassen kann (z.T. tut es das
 AFAIK), ist das auch da behoben.
 Die Abfrage Westring, Kiel liefert etwa 50 einzelne Straßensegmente.

Das Problem steht irgendwo auf der Todo-Liste. Die Lösung dazu wird aber
mit Sicherheit nicht aus der Auswertung irgendwelcher Strassenrelationen 
bestehen.


Auf wessen Todo-Liste und woher nimmst Du diese Sicherheit?  Klingt wie ein 
Alleingang.


Gruß
Christian



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

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

[Christian Müller]

Peter Wendorff wendo...@uni-paderborn.de schrieb:

Am 17.07.2012 13:22, schrieb Christian Müller:
 Sarah Hoffmann lon...@denofr.de schrieb: [...]

 Auf wessen Todo-Liste und woher nimmst Du diese Sicherheit? Klingt wie ein 
 Alleingang.
Alleingang nicht unbedingt, aber da Sarah Nominatim-Maintainerin ist, 
würde ich das mal so akzeptieren ;)

Bitte mal melden.  Falls hier noch ein paar Stimmen zusammenkommen, können wir 
endlich diesen leidigen, zähen und trägen Community-Prozess abschaffen.  Ich 
wäre dann für eine Umfirmierung in OfDSM - OpenforDevsStreetMap.  Oder 
CfjmaraSM - ClosedforjoemapperandrelationaddictsStreetMap.

Apropos Nominatim - da könnte man erstmal is_in aufräumen..  Da werden 
teilweise Gebiete nach ausdehnungslosen place=region nodes benannt, die 
hunderte km von den Objekten, zu deren Bennenung sie herangezogen werden, 
entfernt sind.  Das ist so gravierend, dass Mapper note= an ihre Gebiete 
hängen, und sich fragen, warum nach dem vierten Komma ein Begriff steht, den 
sie überhaupt nicht zuordnen können. 

Das soll explizit kein rant an die maintainerin sein, aber es passt thematisch 
ganz gut hier her und ist imho wichtiger, als Lösungen dort zu finden, wo 
bereits funktionierende bestehen.


Gruß
Christian


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

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

[Christian Müller]

Am 17.07.2012 08:38, schrieb Frederik Ramm:
Jede Relation modelliert eine bestimmte Art von Beziehung, und diese 
Beziehung muss man verstehen, um sie richtig editieren zu koennen.


+1


Allein schon die einfache Frage: Ein Way, der in einer Relation 
steckt, wird zweigeteilt; wie wirkt sich das auf die Relation aus? 
kann nicht beantwortet werden, ohne die Relation zu verstehen.


Das sehe ich nicht so.  Fällt Dir ein Beispiel ein?  In JOSM ist der 
Standardfall, den dadurch neu enstandenen Weg an gleicher Position 
einzufügen.  Dieses Verhalten ist mir in den letzten Jahren nicht einmal 
negativ aufgefallen - weder bei MPs, noch bei Routen, noch bei sonst 
irgendwelchen Relationen..



Oder: Ein Way, der in einer Relation steckt, wird geloescht. Soll die 
Relation mitgeloescht werden, soll sie ohne diesen Way weiterbestehen, 
oder muss ein Ersatz-Way in die Relation aufgenommen werden?


Das entscheidet der Mapper - die Software muss hiervor geeignet warnen, 
bzw. die Auflösung dieser Fälle unterstützen.  Speziell für Löschungen 
sieht JOSM solche Warnungen vor und bietet geeignet Alternativen an - 
gerade auch beim split / join von ways mit Relationen, wie es mit 
Potlatch aussieht, ist mir unbekannt.






Die Abfrage Westring, Kiel liefert etwa 50 einzelne Straßensegmente.


Ein Way mit dem Namen 'Westring' ist Mitglieder einer Relation. Der 
Name des Ways wird nun auf 'Suedring' geaendert. Muss er deswegen aus 
der Relation entfernt werden... ;)


Das kommt darauf an - wenn die Änderung korrekt ist und die Wirklichkeit 
reflektiert vermutlich schon.



Eine Relation fuer den Westring in Kiel ist dann sinnvoll, wenn sie 
auch Objekte mit anderem Namen als Westring enthalten soll. Soll sie 
das nicht, dann kann man sich die Relation sparen.


Gibst Du bitte eine Heuristik an, die präzise genug entscheiden kann, 
wie der Objektzusammenhang ist?  Selbst auf Hausnummern als 
unique-Kriterium wäre kein Verlass, denn die sind ggf. doppelt oder gar 
nicht in der DB.


Es kann durchaus zwei unterschiedliche Straßen mit gleichem Namen in 
Gebieten geben, die nicht durch zwei einfache bboxes auseinanderzuhalten 
sind.


Weiterhin, verzichtet man auf die bbox-Methode und geht das Problem mit 
den postal_code-boundaries an, eröffnet sich das Szenario, dass an deren 
Grenzen eine gleichnamige Straße die postal-boundary schneidet - sind 
das dann zwei verschiedene Straßen oder eine?  Zudem müßte hierfür bei 
der Post erfragt werden, ob Straßennamen pro postal_code per Definition 
Post wirklich immer eindeutig sind - imho yes, aber genau weiß ich das 
nicht.


1) Nehmen wir an, Straßenzshg. werden über type=street durch Mapper 
modelliert:  Für eine bbox B lassen sich dann alle Straßen mit Namen N 
einfach per  Overpass oder SQL abfragen.


2) Nehmen wir nun an, Du hast eine Heuristik entwickelt, die trotz 
mannigfaltiger Geometrien in the wild mittels Bestimmung anhand von 
nearby- bzw. node-matching Algorithmen halbwegs genau Straßensegmente zu 
einer Straße zusammenbasteln kann.


-  Ohne ein neues Objekt in der DB oder in Overpass zu schaffen, 
welches deine Heuristik kapselt und demzufolge zur Ermittlung mehrerer N 
in B ersatzweise zu 1) verwendet werden kann, ist das nutzlos.  Denn 
während ich für die Instanz B=Bayern und N=Goethestraße mittels 1) ohne 
Probleme Resultate erhalte, kann ich das mittels 2) ohne Kapselung gar 
nicht oder nur so kompliziert, dass es niemand je benutzen wird.


- Nehmen wir also an die Heuristik wird gekapselt und sorgt dafür, 
Straßenzusammenhänge tatsächlich richtig zu ermitteln.  Dann erfüllt sie 
den gleichen Zweck wie Relationen vom Typ type=street.  Mit dem 
Unterschied, das letztere von Menschen gepflegt wird und erstere von 
demjenigen, der die Heuristik erstellt - jemandem, der nie lokales 
Wissen besitzt, aber alle Fälle genügend genau approximieren können muss.


Feststellungen:

- falls es diese Heuristik gibt und sie befriedigend genau 
arbeitet, dann muss sie noch entwickelt werden, andernfalls wäre zu 
fragen, weshalb sie noch nicht für OSM benutzt wird
- es wäre ein API-Wechsel, entweder bei OSM oder Overpass, nötig, 
der die Heuristik als abfragbares Objekt auf dem Server hinterlegt
- die Heuristik anzuwenden benötigt Rechenzeit - 'bottleneck' 
wurde als Problem bereits angesprochen


- falls Relationen weiterhin als unnötiges Hexenwerk angesehen 
werden, wären diese Schritte für eine Zahl weiterer Relationen zu 
wiederholen (type=waterway e.g.)
- _einem_ Entwickler würde die Aufgabe übertragen eine Heuristik zu 
finden, die genügend genau für _alle_ funktioniert, das dann zu kapseln 
und als abfragbares Objekt in der DB oder abgeleiteten Projekten zu 
implementieren



Genauso mit Bundesstrassen - eine Relation, die exakt alle Objekte mit 
ref=B10 enthaelt, ist unnoetig. Verlaufen irgendwo die B10 und die B12 
ein Stueck auf dem gleichen Asphalt, dann wird sie sinnvoll, denn ein 
ref=B10,B12 am Way will niemand auswerten.


Nein, dadurch 

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

[Christian Müller]

Peter Wendorff wendo...@uni-paderborn.de schrieb:

 Nein. Wie der ANWENDER die Daten bekommt, ist den meisten Entwicklern 
 tatsächlich egal; nur sollten die Informationen, wo möglich, auch außerhalb 
 der Relation vorhanden sein, weil sie sonst von den Anwendungen oft ignoriert 
 werden.


Das ist jetzt nicht dein Ernst oder?  Wir taggen weder für Renderer, noch für 
bestimmte oder spezielle Anwendungen.  Wenn eine Anwendung nicht mit Relationen 
umgehen kann, ist das in erster Linie Problem der Anwendung, solange die 
Relation einen Sachverhalt der Realität adäquat modelliert.

Auf Relationen wird nicht aus Gründen der Anwendungskompat. verzichtet, wenn 
sie der klar einfachere und intuitive Weg sind, Daten einzutragen.

Es ist Entwicklern hier ganz klar nicht egal, wo die Daten herkommen, denn aus 
ihrem Kreise kommt der verständliche Wunsch, dass Sammelrelationen explizit 
nicht (mehr) aus der main db kommen sollten.  Wäre es ihnen egal, könnten sie 
so belassen werden, denn selbst wenn sie redundant sind, sie modellieren einen 
Ausschnitt der Realität adäquat.

Eine B 2 kann eben sowohl als Route als auch als Eigenschaft des Weges B 2 zu 
sein, aufgefasst werden.


Gruß
Christian


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

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

[Christian Müller]

Peter Wendorff wendo...@uni-paderborn.de schrieb:

Wenn eine Anwendung nicht mit Relationen umgehen kann, ist das ihr 
Problem, das ist richtig.
Wenn aber die Nutzung von Relationen die Hürde sowohl für 
Anwendungsentwickler als auch für Mapper anhebt, dann ist das für mich 
ein eindeutiges Signal, dass es anders vermutlich besser ist.
 Auf Relationen wird nicht aus Gründen der Anwendungskompat. verzichtet, wenn 
 sie der klar einfachere und intuitive Weg sind, Daten einzutragen.
Richtig. Momentan sind sie das aber nicht - weder einfach noch intuitiv 
einzutragen - und noch weniger gut korrekt zu halten.

Das ist Ansichtssache.  Ich finde sie einfach und intuitiv und möchte in 
Gebieten mit hohen Datendichten diese Art der Modellierung nicht missen.  Sie 
erhöht die Verständlichkeit und Übersichtlichkeit enorm.  Zudem beendet sie das 
Gezerre um die Debatte, ob Wege überlappend oder ganz dicht beieinander 
gezeichnet werden sollen.  Man zeichnet eine Flächengrenze und ordnet diese den 
Flächen zu, an denen sie 'teilnimmt' - fertig.


Im Prinzip wiederholst Du hier einen ähnlich gelagerten Fall, der zwischen

  - nur POI für ein Geschäft
  - nur building+tags für ein Geschäft
  - beides parallel eingetragen

bestand.  Es gab einen Zeitpunkt, da reichte es aus, nur die POIs zu 
betrachten, aber der OSM-Planet hat sich weiter gedreht und sämtliche Software, 
die heute ernsthaft Geschäfte auswertet, wertet getaggte buildings aus (und 
transformiert ggf.).

Gleiches wird auf absehbare Zeit für Relationen gelten, insbes. MPs.  Wenn es 
eine legacy Software gibt, die damit nicht umgehen kann, müssen die Daten 
geeignet transformiert werden - wie das z.B. m.W. mkgmap für die POIs macht.

Eine einfache Fläche gleich als MP anzulegen, bedeutet gewissermaßen 
Zukunftssicherheit, denn i.d.R. grenzt jede Fläche an irgendeine oder mehrere 
andere.  Der closed way ist hier nicht die bessere Darstellungsform, sondern 
ein Überbleibsel aus den Anfängen von OSM.  Er wird allenfalls der 
Bequemlichkeit wegen oder weil man es nicht besser weiß verwendet.

Er lässt sich mal schnell eben grob anlegen ohne weiter nachzudenken, aber für 
die langfristige Pflege der Daten eignet sich ein MP viel besser, weil nur die 
Abschnitte der Flächengrenze betrachtet/geändert werden müssen, die auch 
bearbeitet werden sollen, statt immer den kompletten closed way zu bearbeiten.  
Je größer oder komplexer die zu bearbeitende Fläche ist, umso spürbarer wird 
dieser Vorteil.


Dein Argument, dass Relationen die Hürde anheben, empfinde ich als 
hypothetisch.  Relationen und im speziellen MPs sind als Lösung für Probleme 
entstanden, die es vorher gab.  Wer sich davon abwendet, kehrt zu den alten 
Problemen zurück - schwacher Datenzusammenhang, approximative Rechnerei als 
Krücke fehlender Relationen, etc. pp.  Ich empfinde als bedenklich, sie zu 
vermeiden, nur weil sie schlecht gepflegt werden oder von Editoren nur 
beschränkt unterstützt werden, von unnötigen Sammelrelationen, die sich 
eindeutig anders zusammensetzen lassen, einmal abgesehen.

Das hat etwas von Selbstgeißelung.  Ich mache mir doch auch keine Gedanken 
darüber, ob es ohne Gesundheit geht, nur weil das Gesundheitssystem schlecht 
funktioniert..


Gruß
Christian



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

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

[Christian Müller]

Am 11.07.2012 07:53, schrieb Manuel Reimer:
Zudem wäre mal eben nachmalen auch einfacher wie Wege zerstückeln 
und dann alles in Relation kippen. Folge der Relationen ist, dass die 
Wanderwege von Unwissenden immer wieder kaputt gemacht werden. Man 
wird also schon deshalb nie arbeitslos werden, weil man immer mal 
wieder von jemandem verbundene Wege wieder aufsplitten darf, um 
Linienzüge in Relationen wieder ganz zu machen. 


Das passiert auch mit Wegen generell - die werden ebenso regelmäßig 
repariert.  Da beschwert sich niemand.


Was hier fehlt, sind eine stärkere Editorintegration, um Relationen zu 
bearbeiten.  Es ist doch ein Modus denkbar, der genauso, wie Du es 
beschreibst, das Nachzeichnen erlaubt, aber im Hintergrund einfach 
Wegsegmente bildet und die in eine Relation kippt.


Für Routenrelationen würde eine Relation ausgewählt und in der Folge

- alle neu angelegten Wege im Hintergrund addiert
- Wege, über die gezeichnet wird, entsprechend gesplittet bzw. in 
Gänze hinzugefügt


Josm hat da in letzter Zeit viele kleinere Verbesserungen erhalten, z.B. 
ist es nicht mehr notwendig, jedesmal den Dialog einer Relation 
aufzurufen, wenn Elemente hinzugefügt werden sollen.  Das lässt sich nun 
auch über Rechtsklick erledigen. Evtl. wird die Handhabung von 
Relationen in Zukunft noch stärker integriert, anstatt (durch den 
Dialog) wie ein Zusatzfeature zu wirken.



Woher weißt du eigentlich bei aneinandergereihten Gebäuden, ob die 
Wand an der Stoßstelle wirklich nur eine Wand ist? In aller Regel 
gibt es diese Wand in der Tat zweimal.


In diesem Fall liegen sie dann aber auch nebeneinander ;-)  Ich weiß, 
dass das (noch) Haarspalterei ist - aber mit der Verfügbarkeit der 
letzten Bing-Bilder sind ja nun mittlerweile auch die Gulli-Deckel 
sichtbar geworden..



Gruß
Christian



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

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

[Christian Müller]

Tobias Knerr o...@tobias-knerr.de schrieb:

 Das Einzeichnen aneinander gebauter Gebäude mit overlapping ways ist
also nicht bloß bequemer und verständlicher, sondern auch 100% korrekt.

Meinetwegen, jeder Architekt und jedes Katasteramt würde das zwar eindeutig 
anders sehen, aber für OSM ist es momentan wohl ausreichend - 100% korrekt 
würde ich in diesem Zshg. nicht verwenden.


 - wegen der Gesamtlänge ohnehin MP mit zerlegten outers brauchen.

Ja, aber Du verwendest auch für eine Ländergrenze mit nur 4 nodes ein MP - ganz 
einfach weil das dort usus ist.

So, umgekehrt hast Du nun zigtausend Gebäude, zu denen es nicht mehr Infos gibt 
(evtl. geben sollte), als ein Umrißrechteck.  Heißt das dann für Dich, weil 
es bei Gebäuden so üblich ist, dass Du auch echt komplexe Gebäude, wie 
innerstädtische Bahnhöfe oder überdimensionierte Einkaufstempel ohne MP 
modellieren willst?

Du schreibst es ja selbst, es ist eine Frage der Komplexität.  Schau Dir z.B. 
den Hbf Berlin mit mehreren Ebenen an.  Solange man dort nur das Umrißrechteck 
zeichnet, kommt man ohne MP aus, zugegeben.

Mit jedem Detail wächst aber der Datenbestand, closed ways werden länger, oder 
überlappen sich z.B. bei drei Geschossen und der Modellierung von Halle und 
innenliegendem Raum schon so sechs Mal.  Um Bezüge herstellen zu können 
schreibst Du deine eigenen Algorithmen und ärgerst Dich dann, das irgendwo ein 
Node aus der Reihe tanzt, manche Mapper legen sich den extra an, weil sie nicht 
wissen, wie sie sonst den fünften von sechs überlappenden Wegen selektieren 
sollen.

Anders mit MPs, da zeichne ich einmal die Wände und kann dann Räume, Umriße und 
Hallen, etc. in Bezug setzen.


 Gebäude sind daher ein Musterbeispiel für einen Fall, wo eine pauschale 
 Modellierung über mehrere Ways und eine Relation statt einen einzelnen Way 
 wirklich total fehl am Platz wäre.


Ok, aber das gilt m.E. nur, solange nicht mehr als ein Umrißrechteck drin ist.  
Sobald Innenhöfe, Rolltreppen, Aufzüge, mehrere Ebenen und Innenräume 
hinzukommen empfinde ich overlapping ways als fehleranfälliger und 
umständlicher in der Wartung.  Zudem ist die Wahrscheinlichkeit höher, dass 
alles heruntergeladen wird und Konflikte beim Editieren erzeugt werden, obwohl 
ich bsp.-weise nur am Westflügel eines Geb. interessiert bin, oder nur am UG..

Andererseits ist Indoor-Mapping so und so nicht einfach, da hier eine andere 
Rechtslage besteht (Hausrecht statt Panoramafreiheit).




Gruß,
Christian


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

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

[Christian Müller]

Hi,


Am 10.07.2012 08:33, schrieb Sarah Hoffmann:

Kannst du konkrete Beispiele nennen von Anwendern, die irgendeiner Relation
ausser den drei wirklich gebrauchten (Routen, Abbiegerelation,
Multipolygon) nachweinen würden?


Es ist deine Ansicht, dass dies die drei einzigen sind, die wirklich 
gebraucht werden.  Du kennst das Wiki, Leute haben sich über Jahre 
Gedanken darüber gemacht, wo deren Meinnung nach Relationen sinnvoll 
sind.  Ich denke nicht, dass Du intensiv genug geforscht hast, um deren 
Arbeit mit ein bisschen m.E. zu entkräften.  Ich persönlich habe in 
letzter Zeit waterway, bridge, site Relationen genutzt.


Speziell bei den waterways erhältst Du z.B. keinen eindeutigen Strang 
von Quelle zur Mündung.  Auch eine Relation garantiert da nichts, aber 
wenn ich mir vorstelle, dass ich mir einen Hauptflusslauf erstmal Weg 
für Weg über Overpass oder einer lokalen DB ziehen müsste, mit einem gut 
möglichen overhead von 2/3 falschen Positiven, kommt mir das Grauen.  
Z.B. gibt es viele gleich benannte Nebenarme, Fahrrinnen, Schleusenarme, 
etc. - ich verlasse mich auch nicht auf die Relation allein, verwende 
sie aber als Ausgangspunkt.  Weiterhin siehst Du z.B. am Rhein-Delta, 
dass ein Tag-Matching+Node-Verbindung nutzender Algorithmus versagen 
wird, denn in den Niederlanden heißt der Rhein schonmal Rijn und fließt 
über Waal, Lek, etc. ab.  Das sind nur ein paar der Spezialitäten, die 
mir hier anwendungsspezifisch einfallen, es gibt sicher 'zig andere, 
aber nicht jeder hat die Zeit und die Muße auf dieser Liste gegen den 
Minimalismus anzukämpfen.




Wie Jochen bereits gesagt hat, muss man für die meisten Sachen den
Fall ohne Relationen ohnehin implementieren, weil es dieser Fall
immernoch der häufiger gebrauchte ist.


Ja, aber er ist die klar schlechtere Approximation gegen eine 
gewissenhaft gepflegte Relation.  Im Prinzip sollte das Fallback-Methode 
sein.  Ich stimme zu, dass es für viele Relationstypen Nachholbedarf bei 
der Spezifikation gibt, um etwa einen ähnlich guten Dokumentationsgrad, 
wie bei den MPs zu erreichen.



Relationen sind wesentlich leichter versehnlich kaputt zu machen als 
Nodes, Wege und Tags, weil sie unsichtbar im Hintergrund herumlungern 
und man nicht sofort sieht, dass man da etwas ändert. 


Mit der von Dir erstellten Cycling-Map (Kompliment übrigens) weißt Du 
doch, wie man sie sichtbar macht.  Ich finde nicht, dass die 
Unsichtbarkeit ein Argument gegen Relationen ist und finde umgekehrt, 
dass z.B. auch nicht verbundene Nodes wenn sie Nahe beieinander oder 
aufeinander liegen, schwer identifizierbar sind.  Zudem werden die 
Routen auch in Editoren visualisiert, das kam auch nicht über Nacht.  
Visualisierungen für andere Relationen werden auch kommen, je nach Bedarf.



Wenn du dir zuviel dieser Freiheiten herausnimmst, schränkst du 
gewaltig die Freiheiten der anderen Mapper ein. Siehe oben. Relationen 
sind in erster Linie ein Hindernis für deine Mitmapper. Es geht nicht 
darum, 'einheitlich' zu mappen, es geht darum, das ganze so einfach 
wie möglich zu halten, damit es für alle verständlich bleibt. 
Ausserdem sind Relationen ein Motivationskiller, wenn es darum geht 
Fehler zu korrigieren. Wer mag schon einen Weg anfassen, der Mitglied 
in 15 Relationen ist. Ein Weg mit 15 kryptischen Tags ist zwar auch 
ein bisschen lästig, aber normalerweise kann man die Tags einfach 
ignorieren, frei nach dem Motto 'leben und leben lassen'. 


Das ist total subjektiv.  Verlege ich den Weg mit 15 kryptischen Tags, 
ohne mir deren Inhalt anzuschauen, entstehen Fehler in evtl. größerem 
Maße, als wenn jemand Relationen bricht, die ein anderer nachpflegt.  
Natürlich bedeutet das alles Aufwand, der vergrößert sich aber ohne 
Relationen nur.  Ich bin der Auffassung, dass in Gebieten mir hoher 
Datendichte und evtl. auch vielen Relationen es unabdingbar ist, dass 
sich ein Mapper Gedanken macht, /was/ er /wie/ ändert.  Ob er da, für 
den Fall er macht sich keine Kopf, 15 Relationen bricht oder 15 
kryptische Tags dorthin verlängert, wohin sie nicht gehören, spielt eine 
untergeordnete Rolle.  Es geht immer zu Lasten derer, die gewissenhaft 
arbeiten.  So ist das nunmal - wie sagtest Du:  das ist kein technisches 
Problem, sondern ein menschliches..




Für mich bedeuten Relationen Flexibilität - u.U. oft auch, dass ein und
der gleiche geografische Sachverhalt eben vielfältig modelliert werden
kann.  Warum begreifen wir das nicht weiterhin als Chance?  Warum wird
stattdessen der Perfektionismus in primitiveren, unstrukturierten Daten
gesucht, wie es Knoten und Weg nunmal sind?

Geografische Sachverhalte sollte man über Geometrie ausdrücken und
nicht durch irgendwelche künstlichen Strukturen. Natürlich könnten
wir für jede Bushaltestelle eine Relation erstellen, die besagt, ob
sie jetzt rechts von der Strasse liegt oder links. Aber was ist der
Sinn? Diese Information ist bereits in der DB, das heisst die Relation
bringt absolut nichts.


Siehe unten, Beispiel Liste 

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

[Christian Müller]

Am 10.07.2012 09:43, schrieb Frederik Ramm:
Das ist ein Missbrauch von Relationen, und wenn ich solche Sammlungen 
sehe, loesche ich sie.


Relationen sind *nicht* dazu da, um Objekte in praktische Eimer fuer 
das Herunterladen zu sortieren.


Siehe auch: 
https://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories


Der Theorie dazu schließe ich mich an, nur wenn die Praxis so aussehen 
soll, dass jeder, der einen längeren Wasserlauf, das Netz der 
Bundesstraßen, etc. laden will, Overpass kennen, lernen und nutzen muss, 
um diesen praktischen Eimer zu vermeiden, funktioniert das /praktisch/ 
nicht.


Die Leute legen diese Eimer an, weil es praktisch ist und weil sie keine 
Alternativen kennen / haben.  Nicht jeder legt sich einen planet dump 
auf seinen Rechner und bastelt sich anschließend seine persönlichen 
Anfragen.


Es ist unpraktisch größere Gebiete als bounding box zu laden, wenn man 
doch nur sehr wenige Features darin braucht.  Deshalb existieren solche 
Sammlungen.  Der Sache quasie mit dem Feuerlöscher hinterherzulaufen, 
ist auf Dauer ebenso unpraktikabel.  Was fehlt sind Alternativen


- vielleicht ein paar Presets an Overpass-Queries für die 
häufigsten, falsch angelegten Relationen in den Editoren


Anstatt die falsch angelegte Relation einfach zu löschen, verschiebt 
man sie.  Z.B. könnte unter Verwendung der gleichen ID ein 
Overpass-Preset angelegt werden.  Damit wäre das ein echter Ersatz für 
die Relation-ID.  Hinter der Preset-ID


   - e.g. overpass-api.de/api/preset/12345

stünde dann eine (Overpass-)Anfrage, die den Inhalt generiert, den die 
unerwünschte Relation gehabt hätte.



Damit hätten wir auch gleich ein hübsches Kriterium, wann eine Relation 
überflüssig ist - ganz grob:  lässt sie sich durch ein Overpass-Preset 
ersetzen (ohne das Overpass in der Flut der Anfrage sinkt), ist sie 
überflüssig.




Gruß
Christian

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

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

[Christian Müller]

Am 10.07.2012 17:09, schrieb Frederik Ramm:
 Also: Relationen, deren Hauptzweck das einfachere Abrufen der Daten
 ist, sind nicht ok. Und die von Dir angebrachte Begruendung andere
 Methoden sind halt zu schwierig mag zwar stimmen und sie koennte ein
 Grund dafuer sein, dass diese Relationen entstehen, aber sie ist keine
 *Berechtigung* fuer diese Relationen.

+1  anders wollte ich das eigentlich auch nicht verstanden wissen. 
Dennoch wäre es wesentlich einfacher, die Ersteller solcher Relationen
davon zu überzeugen, es nicht zu tun, wenn es eine brauchbare, einfache
non-sql-hacking Alternative gäbe.  Ob die alternativlose Löschung auf
Dauer überzeugt, ist doch fraglich.  Ich denke, wenn es eine
Community-pflegbare Liste von Preset-Queries auf die ein oder andere
Weise auf Overpass geben würde, fänden sich genügend Leute, die helfen
categories aus der main db zu entfernen.

Allerdings bedeutet diese Umverteilung von Information (preset-query
statt explizite Sammelrelation) auch eine gewisse Dezentralisierung und
es ist mehr als fraglich, ob sich diese Verfahrensweise beim Umgang mit
gewünschten Kategorien dann außerhalb D verbreitet und auch dort
überzeugt.  Parallel zum planet dump bräuchte es dann auch einen
preset-query dump, um das mal etwas weiter zu spinnen.


Gruß

ps:  nein, ich schreibe vielschichtige mails nicht, damit die Leute
weglaufen..

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

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

[Christian Müller]

Am 10.07.2012 17:56, schrieb Manuel Reimer:
 Christian Müller wrote:
 Der Theorie dazu schließe ich mich an, nur wenn die Praxis so
 aussehen soll,
 dass jeder, der einen längeren Wasserlauf, das Netz der
 Bundesstraßen, etc.
 laden will, Overpass kennen, lernen und nutzen muss, um diesen
 praktischen
 Eimer zu vermeiden, funktioniert das /praktisch/ nicht.

 Warum? Was ist so falsch daran, mal bei den Wissenden nachzufragen,
 wie man X aus der DB fischen kann?

Das kann ich Dir auch nicht abschließend beantworten.  Ich reflektiere
nur den durch mich wahrnehmbaren, aktuellen Stand der DB und versuche
Gründe zu finden, weshalb die deiner Meinung nach unwissenden in einer
Vielzahl von Fällen auf die Komplexität (oder Einfachheit) von X aus
der DB fischen verzichten und Relationen für Zwecke verwenden, die
jenseits dessen liegen, was von ihren Designern angedacht war.

Und Overpass funktioniert ja nun auch noch nicht ewig, vorher war zwar
das unflexiblere Xapi da, aber beides scheint nicht als Alternative zur
Sammelrelation wahrgenommen zu werden.  Es ist auch nicht das gleiche -
stell Dir vor, die Community des Wiki-Projekts Germany würde die
Bundesstraßen nicht über Relationen pflegen - im Wiki müssten sie nun
ellenlange Overpass-URLs angeben, um sich auszutauschen oder Templates
für Overpass bauen.  So wird stattdessen einfach das Template für die
Relationen wiederverwendet und man erhält eine Vielzahl von Links
obendrauf (remote josm link, relation analyzer, etc. pp.).  Es scheint
also eine ganze Menge Vorteile zu geben, Relationen zu missbrauchen,
anstatt Overpass-Queries hin- und herzuschieben.  Evtl. ändert sich das
jetzt mit der starken Verfügbarkeit von Overpass, wer weiß.

 - Relation und schnell bestimmte Daten abrufen bedeutet, gerade
 bei unwissenden, häufig auch, dass die die normale API dafür
 missbrauchen wollen. Die ist für solche automatischen Abfragen aber
 nicht gedacht!

Mir brauchst Du das nicht erzählen ;-)  Und das Argument nicht dafür
gedacht, nun ja, ich muss Dir nicht erzählen, dass Pudel und Handys in
Mikrowellen getrocknet werden?  Dass die Thermoskanne statt für
Heißgetränke auch zum kühl halten verwendet wird?


Gruß
Christian


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

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

[Christian Müller]

Am 10.07.2012 18:02, schrieb Manuel Reimer:
 Frederik Ramm wrote:
 (Zugegeben: Genauso, wie wir Nutzer nicht zwingen sollten, ohne Not
 Objekte zu
 logischen Konstrukten zusammenzufassen, so sollten wie sie auch nicht
 zwingen,
 eine eigentlich zusammengehoerende Strasse in Stuecke zu hacken,
 bloss weil ein
 Tempolimit kommt oder der Bus abbiegt...)

 Gibt es denn dafür eine Alternative? Um das Tag Tempolimit auf 30
 korrekt zu setzen, muss man die Straße doch zerschneiden, wenn nicht
 die gesamte Straße betroffen ist. Für die in Relationen angelegten
 Wanderrouten ebenfalls, denn man legt ja nur das Stückchen Weg in die
 Relation, auf dem die Route verläuft.

imho gibt es dazu keine Alternative.  Es sei denn man verbietet Wege in
Relationen zukünftig und definiert auch die Routen nur über nodes - um
letztere wiederzuverwenden, bräuchte man einen Weg nicht zu zerhacken.

Relationen mit anonymen Punkten zu pflegen dürfte hingegen niemandem
Spaß machen, zudem wächst die Mitgliederzahl in Relationen.
Zugegeben, in Gebieten mit hohen Datendichten werden Wege so stark
zerhackt, dass der Abstand zur Nutzung der Einzelnodes ohnehin nicht
mehr groß ist.  Das betrifft aber gerade bei Routen vorzugsweise nur die
Teilabschnitte, die durch Städte verlaufen.  Über Land dürfte die
Einsparung der Listenlänge, dadurch dass way_ids statt node_ids
verwendet werden, enorm sein und bleiben.


Gruß
Christian

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

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

[Christian Müller]

Am 10.07.2012 20:48, schrieb Peter Wendorff:
 Mit Relationen für Bundesstraßen und ähnlichen Blödsinn gibt es ja
 (zum Glück) auch keine Sammlung von Relations-IDs, die man komplett
 herunterladen kann, sondern höchstens einzelne Relationen, die auf
 einzelnen Wikiseiten verlinkt sind oder so.

Es wird hier argumentiert, dass eine einzelne Bundesstraßenrelation an
sich schon Blödsinn ist, da sie Wege sammelt, die durch eine einfache
ref=query ebenso erhalten werden können.  Ich bin gegen individuelle
Queries - wenn sie ein Ersatz für Sammelrelationen sein sollen, müssen
sie öffentlich und damit diskutier- und im Notfall auch änderbar sein. 
Eben so, wie die Sammelrelation auch öffentlich einseh- und änderbar ist.


 Ob da (im wiki) aber jetzt ein /browse/relation/#-link steht oder eine
 z.B. overpass-query, ist doch sch***-egal.

Aus Anwendersicht schon, soll auch so sein.  Aus Entwicklersicht
offenbar nicht.


Gruß
Christian

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

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

[Christian Müller]

Am 10.07.2012 20:52, schrieb Peter Wendorff:
 Am 10.07.2012 19:48, schrieb Christian Müller:
 imho gibt es dazu keine Alternative.  Es sei denn man verbietet Wege in
 Relationen zukünftig und definiert auch die Routen nur über nodes - um
 letztere wiederzuverwenden, bräuchte man einen Weg nicht zu zerhacken.
 Sorry, aber jetzt wirds stumpf.
 Jetzt willst du eine Relation benutzen, um eine geordnete Liste von
 Nodes zu erhalten, die dann im editor  am besten auch noch als
 Linienzug dargestellt wird?

Der Vorschlag ist gar nicht mal von mir - er kam im Zusammenhang mit
ÖPNV-Relationen schonmal, weil sich deren Mapper beschweren, dass die
Relationen durch Geometrieänderungen der Wege häufig zerstört werden. 
Die Theorie ist, nur bestimmte nodes zu mappen und den Rest durch einen
Router erledigen zu lassen.

Ich stimme Dir zu, dass overlapping ways dem Nahe kommen.  Nur ist die
Fangemeinde von overlapping ways auch nicht besonders groß, da sie
ebenso wie mancher Relationstyp schlecht oder gar nicht visualisiert werden.

Aneinandergereihte Gebäude nutzen häufig overlapping ways, da stimme ich
Dir ebenso zu.  Eigentlich gibt es die Wand nur einmal, welche da durch
zwei Wege in OSM repräsentiert wird.  Das geschieht aus Bequemlichkeit,
nicht weil es logisch und/oder plausibel ist.  Streng genommen müßte ein
MP her, welches die Wand in Bezug zu den Gebäuden setzt, an denen sie
teilnimmt.  Wir zeichnen auch Ländergrenzen nicht doppelt.


Gruß
Christian



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

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

[Christian Müller]

Am 10.07.2012 21:21, schrieb Peter Wendorff:
 Wenn ich einen overpass-link erzeuge wie (nicht geprüft, nur
 schematisch) [bbox=][highway][ref=B 7], dann kann man anhand
 !dieses Links! genausogut diskutieren wie anhand der relations-id
 0815, die die gleichen Elemente enthält:
 - Das Abfragen ist genauso einfach (wenn ich osm.org/browse/* mal
 ausnehme, das bricht nämlich gerade bei großen Relationen sowieso
 regelmäßig zusammen).
 - Das Verteilen des Links ist genauso einfach, nämlich in beiden
 Fällen per CopyPaste
 - Das Ändern des Inhalts ist einfacher: ich muss mich nämlich gar
 nicht darum kümmen, solange ich das ref-Tag richtig setze
 - Das Ändern des Links ist auch nicht schwieriger; wenn man das
 überhaupt braucht (dürfte nur dann der Fall sein, wenn auf einmal z.B.
 die gerade neu eingetragene B 7 in Österreich zufällig die BoundingBox
 überschneidet)

+1 Ist doch alles richtig.  Die besagten B-Relationen waren nur ein
Beispiel, um das Problem an sich zu verdeutlichen - nicht alle derzeit
verwendeten Sammelrelationen dürften auf diese Weise ersetzbar sein. 
Weiterhin fehlt:

- remote josm link
- die von dir schon angesprochene /browse/ -Geschichte
- außerdem dürfte es nervig sein, die bbox in jeder URL anzugeben
(hier würden Aliase der admin. Grenzen helfen, etwa [bbox=Europe,Germany])

Zudem ist zu schauen, was momentan eigentlich in der Relation gepflegt
wird  - evtl. sind auch Raststätten, Notrufsäulen etc. dabei, welche die
Query ebenso liefern muss, will sie die Relationen ersetzen.  Versuche
eine Query für Overpass zu finden, welche Dir alle Brücken über x
(x=Rhein, Elbe, etc.) liefert - das wird kein Einzeiler mehr, sollte es
überhaupt nur mit Overpass machbar sein.


 Ob da (im wiki) aber jetzt ein /browse/relation/#-link steht oder eine
 z.B. overpass-query, ist doch sch***-egal.
 Aus Anwendersicht schon, soll auch so sein.  Aus Entwicklersicht
 offenbar nicht.
 Ich vermute, auch aus Entwicklersicht ist das egal - nur sind es oft
 nicht die Entwickler, die das ins wiki einpflegen, sondern Mapper, die
 es nicht anders kennen.

Gemeint war:  aus Entwicklersicht ist es nicht egal, ob des Anwenders
Daten aus Relation oder Overpass-Query kommt.  Sie bevorzugt (momentan)
letzteres.


Gruß
Christian



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

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

[Christian Müller]

Am 09.07.2012 21:47, schrieb Frederik Ramm:
 Ist halt die Frage, fuer wen. Fuer den Router und den Renderer eben
 nicht.

Genau das ist der Punkt.  Schmeißen wir die Relationen weg, verprellen
wir Anwender und Entwickler bestimmter Anwendungsfälle genau so, wie es
Unkenrufe geben wird, wenn plötzlich Namen einer Straße aus mehreren
Elementen nur noch in der Relation auftauchen.

Mich hat bisher kein einziges Argument gegen Relationen überzeugt. 
Einzig evtl., dass sie schlecht gepflegt sind - das gilt aber auch für
den restlichen OSM-Datenbestand.  Ich sehe z.B. immer wieder nicht
verbundene Nodes, versehentlich verschobene, etc.

Ich kann auch Sarah's Argumenten nicht folgen, dass OSM eine rein
spatiale DB ist.  Es ist ein Mix - whatever works entscheidet, wer wie
etwas modelliert.  Natürlich bedeuten diese Freiheiten Komplexität in
der Auswertung - das ist aber imho dennoch weniger Aufwand, als alle zu
zwingen, einheitlich zu mappen.  Ein Einwirken auf jeden der dann nach
Überlegung falsch mappt, wird denjenigen die Lust am Mappen verderben.

Für mich bedeuten Relationen Flexibilität - u.U. oft auch, dass ein und
der gleiche geografische Sachverhalt eben vielfältig modelliert werden
kann.  Warum begreifen wir das nicht weiterhin als Chance?  Warum wird
stattdessen der Perfektionismus in primitiveren, unstrukturierten Daten
gesucht, wie es Knoten und Weg nunmal sind?

Relationen sind auch dort, wo eigentlich alles auf dem Weg getaggt
werden könnte, eine sinnvolle Ergänzung, z.B. um die Übersichtlichkeit
zu bewahren und die Pflege zu vereinfachen.  Sie können evtl. 50+
Übersetzungen halten, während die bsp.-haften, sechs zugehörigen Wege
nur den regional üblichen Namen halten.  Auch mit Lookup-Tables/LUT
versagt irgendwann der minimalistische Ansatz.  Je nachdem, wieviel
Information über eine Menge von Wegen oder Knoten gehalten werden soll. 
Auch wenn LUT evtl. in einigen Software-Projekten anzutreffen sind und
dort eine Tag-Redundanz erfolgreich wegoptimieren, sind sie kaum
dokumentiert und die Art ihrer Implementierung variiert.  Die Live-DB,
die Live-Toolchain verwendet sie nicht.  Zudem wird mit der Auslagerung
von Tags in LUT auch nichts anderes als eine Relation geschaffen, halt
nur nicht vom Menschen.

Wenn wir schon so radikal sein wollen und so einen tollen Leitspruch wie
vermeide Relationen gebären wollen, warum dann nicht gleich auch auf
die Struktur way verzichten.  Eigentlich reicht es doch, wenn wir
alles auf dem Node taggen.  Mapper machen nur Fehler, wenn sie sich mit
der Komplexität eines way's auseinandersetzen sollen.  (..)



Weiterhin spielt die Arbeitsweise beim Mappen in diese Problematik.  Ich
würde weder diejenigen verprellen, die strukturiert arbeiten und sagen:
Ich lege mir Bundesstraßenrelationen an, weil mir dann die Pflege
dieses Netzes einfacher fällt., noch diejenigen, die in einem weißen
Gebiet unstrukturiert alles mögliche anlegen und von Relationen gar
nichts wissen und sie aufgrund des Datenstandes evtl. gar nicht brauchen.

Da die Daten, wie die Softwareprojekte drumrum vermutlich nie perfekt
sind, ist das mehr an Information und evtl. auch Redundanz eine Chance,
gute QM-Tools zu bauen.  Am Beispiel der Bundesstraßen z.B. könnte man
die Argumente derjenigen aufgreifen, die meinen

man könne den Verlauf der Bundesstraße auch programmatisch anhand
des ref= zusammenbauen und braucht die Relation gar nicht

und gegen das prüfen, was manuell gepflegt wird.  In der Summe ergibt
das eine gewisse Robustness gegen die Fehler, die man beim Mappen machen
kann:

- versehentlich Relation beschädigen
- versehentlich ref löschen

Es ist unwahrscheinlich, das beides zeitgleich passiert.  Gäbe es
hingegen eine explizite Relation nicht, würde ein Fehler durch ein
fehlendes ref Tag am way nicht auffallen - allein auf die Heuristik
alle Wege, die sich einen Knoten teilen zu bauen, ist weltfremd und
idealisiert imho viel zu stark.  Hier wünscht sich der Informatiker die
Welt herbei, wie sie sein sollte.  Beispielsweise ist der Verlauf von
Landesstraßen heute vielfach in Teilabschnitten durch Bundesstraßen
ersetzt worden und dadurch fragmentiert.  Weiterhin sehe ich nicht ein,
weshalb, nur weil es für Routing und Rendering abkömmlich ist, auf den
exotischeren Anwendungsfall wieviele Goethestraßen gibt es in X
verzichtet werden sollte, wenn er mit etwas Grips und gutem Willen in
der DB ohne viel Zauber und Zusatzarbeit modellierbar ist.  Die Fragen,
die sich hier viele stellen, ist doch eher, wieviel Relation ist gut? 
Wie kann vermieden werden, dass die Nutzung von Relationen, die spatiale
Verwendbarkeit einer Auswertung auf einfacheren Ebenen wie Punkt / Weg
schadet?


Gruß
Christian



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

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

[Christian Müller]

Am 08.07.2012 11:26, schrieb Peter Wendorff:
Es ist daher auch noch niemand auf die Idee gekommen, jede Straße als 
eine

eigene Relation zu schreiben, um den Straßennamen nicht redundant zu
speichern.


...abgesehen von Ausnahmen wie z.B. Autobahnen, bei denen das IMHO 
auch nicht notwendig wäre.



Ich möchte in dem Zshg. auf [1] verweisen - dato hat fast jede 
Bundesstraße ihre eigene Relation, so auch viele Landes-, bzw. 
Staatsstraßen.  Auch innerorts ist OSM mit immerhin rund 12.000 
Relationen vom Typ street dabei [2], welche gesplittete Wege gleichen 
Namens explizit in Relation setzen.


Dennoch sind Basisinformationen, wie name, ref, highway stets auf den 
Primitiven Weg / Knoten vorhanden.  Anstatt eine Lanze für oder gegen 
die Redundanzfreiheit zu brechen, lassen sich auch positive Aspekte 
einer sich überschneidenden Datenhaltung finden:


- Robustheit
- ist ein Faktum sowohl als Relation, als auch über Tags an den 
Primitiven gemappt, steigt z.B. die Anzahl der Methoden, die QM-Tools 
verwenden können, um Plausibilität und Konsistenz der Daten zu prüfen
- am Beispiel der Bundesstraßen wäre z.B. denkbar, dass man das 
Ergebnis einer errechneten Relation (alle ways mit ref=B x) mit 
gemappten Relationen vergleicht, zusätzlich zu den gängigen Tests auf 
Lücken für Route-Relationen
- im Bezug auf das Tagging entsteht eine Robustheit dadurch, 
dass es unwahrscheinlich ist, dass ein Mapper sowohl auf dem way als 
auch in der Relation versehentlich das gleiche ändert/löscht


- Wartbarkeit / Datenmanagement
- existieren sowohl Relation als auch Primitiven, kann der 
Mapper Information gewichten, d.h. bestimmte Informationen redundant 
halten, andere nicht
- bsp.-weise könnte man sich der Übersichtlichkeit wegen 
entscheiden, auf den Primitiven nur die nötigste Information zu taggen 
(ref/name), während die Relation Zusatzinformation hält (tmc, name:de, 
name:en, name:xyz, ..)
- damit bleiben die einfacheren und vermutlich häufigeren 
Anwendungsfälle auch ohne Relation-Lookup lösbar


- Zugänglichkeit
- Verschiedene Leute verwenden verschiedene Mapping-Methoden. 
Während die strukturierteren Leute sich evtl. gezielt mit einem 
bestimmten Thema beschäftigen (sei es Bundesstraßen, Wasserläufe, 
Geschäfte, etc.) und es demnach begrüßen, wenn sie, statt einem Gebiet, 
gleich über eine Relation die jeweils zu bearbeitenden Daten selektiv in 
ihren Editor ziehen können, um den aktuellen Stand zu prüfen, 
interessiert diese Art des Zugangs den Pionier im relativ datenlosen 
Gebiet kaum.




Gruß
Christian

[1] 
http://wiki.openstreetmap.org/wiki/WikiProject_Germany/Bundesstra%C3%9Fen

[2] http://taginfo.openstreetmap.org/search?q=type%3Dstreet



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

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

[Christian Müller]

Hallo Jan,


siehe Lonvias Rad- und Wanderkarten, oder die ÖPNV-Karte. Wenn Relationen so 
unnütz oder kompliziert auszuwerten wären, würde es diese Karten nicht geben.

spatialite bietet für kleinere Projekte gute Möglichkeiten mit OSM-Daten zu 
arbeiten, erfordert aber etwas Ahnung von SQL.


just my two cts,
Christian
-- 
Nichts ist vollkommen.



Jan Tappenbeck o...@tappenbeck.net schrieb:

Moin !

ich möchte mal wieder eine Frage an die Allgemeinheit stellen auch auf 
die Gefahr hin zerrissen zu werden.

Es geht konkret um ein Zenario was Relationen und Hausnummern betrifft 
und nachfolgend bitte keine Diskussion über diese Relation ist aber 
doof, weil  Es geht um die Frage wie ist soetwas überhaupt 
vernünftig und performant in der Auswertung zu realisieren. Das Beispiel 
kann sicherlich auch auf andere Relationen übertragen werden. Immer 
werden verschiedene Elemente bei Relationen zusammengeführt die 
irgendetwas gemeinsam haben und man so verhindern will das Redundante 
Daten entstehen.

Auf dem letzten Stammtisch in Lübeck [1] haben wir über die 
verschiedenen Geschäfte und die Adressen gesprochen.

Einfacher Fall: in einem Gebäude sind mehrere Geschäfte enthalten. Nun 
macht es keinen Sinn auf jeden POI eine Adresse zu legen und deshalb 
gibt es zum Beispiel die Building-Relation [2] (zu der wir uns in etwas 
abgewandelter Form [1] entschieden haben) um Gebäude, Eingänge, 
Geschäfte miteinander zu verknüpfen. Wie gesagt nur ein Beispiel - 
geiches läßt sich auch auf Straßen-Relationen etc. übertragen 
(Straßenname am Objekt überflüssig, weil Gebäude gehört ja zur Straße).

Die Frage die ich nun stellen möchte - ist es überhaupt irgendwie 
möglich solche Verbindungen performant aufzuschlüsseln? und gibt es 
vielleicht schon Programm(teile) dafür von denen ich nicht weiß.

Ein weiteres Beispiel hierzu. Ich habe das ganze einmal mit der 
OpenLinkMap [3] abgecheckt und da werden solche Verbindungen über 
Relationen nicht ausgewertet. Dann habe ich mich an Alexander gewandt 
und nachgefragt. Ich fasse die ausführliche Antwort kurz zusammen: Er 
sieht keinen einfachen Lösungsansatz dazu und vermutlich wird zuviel 
Performance dabei auf der Strecke bleiben.

Wenn dem so ist - wir zwar nicht für die Renderer (damit auch nicht für 
andere Programme) mappen - ja wofür brauchen wir denn Relationen, wenn 
diese sowieso nur sehr sehr schwer auszuwerten sind???

Also nochmal die beiden Fragen:
* welche Ansätze für die Auswertung gibt es?
* gibt es Software die die Relationen aufschlüsselt - zum Beispiel die 
Daten aus den Relationen auf die beteiligten Elemente überträgt?

Gruß jan :-)

[1] http://wiki.openstreetmap.org/wiki/L%C3%BCbecker_Mappertreffen - 
Archiv-Beitrag Nr. 40 vom 5.7.2012
[2] http://wiki.openstreetmap.org/wiki/Relations/Proposed/Buildings
[3] http//www.openlinkmap.org

_

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

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

[Talk-de] Overpass API - Ergebnis nicht komplett

[Christian Müller]

Hallo,


wenn ich die Relation 123.822 per Overpass-API ziehe, fehlt genau ein
Weg (ID 4943717) in der Ergebnismenge..


Meine Query ist

relation
  [name=Elbe]
  [type=waterway];
way(r);
node(w);
way(bn);
(
  way._
[waterway]
[waterway!=riverbank]
  -.a;
  way._[natural=water]-.b;
  node(w.a);
  node(w.b);
);

Hat jemand eine Idee, woran es liegen könnte?  Alle anderen Wege
erscheinen, nur dieser nicht - ich habe in der History von 4943717
nachgeschaut - alle bisherigen Autoren haben der ODbl zugestimmt, falls
das eine Rolle spielt.


Gruß
Christian

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

[Talk-de] Lizenzvermerk Wikipedia-Karte

[Christian Müller]

Hi,


der Lizenzvermerk zur WIWOSM Karte ist m.E. nicht korrekt.

Es sollte heißen OpenStreetMap _und Mitwirkende_ (CC-BY-SA). [1]

Wenn wir das innerhalb der freien Projekte nicht gut auf die Reihe
kriegen, brauchen wir uns nicht wundern, wenn es in the wild auch
nicht anders aussieht.


LG
Christian

[1]
http://wiki.openstreetmap.org/wiki/DE:Legal_FAQ#Ich_m.C3.B6chte_OpenStreetMap_verwenden._Wie_soll_ich_auf_euch_hinweisen.3F

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

[Talk-de] Boundary Relation - Gebiet / admin_centre im WIWOSM Kontext

[Christian Müller]

Hi,


das wird eine Frage nach den best practices..


In der DB gibt es Relationen der Art

type=multipolygon boundary=administrative
(und wildere Varianten, etwa multipolygon=administrative)

type=boundary boundary=administrative

Im Wiki werden die beiden Typen gleichgestellst, d.h. admin_centre= und
label= können unabhängig vom Wert in type= als Mitglieder direkt in die
(Grenz-)Relation aufgenommen werden.  JOSM versucht das in
http://josm.openstreetmap.de/ticket/7550
aufzugreifen.


Weiterhin gibt es in der DB nun Relationen mit

type=state

Diese sind ein Konglomerat aus admin_centre=, bzw. capital= und
Grenz(-Relation).
Nach Wiki-Lesart sind diese überflüssig, denn imho sind capital= und
admin_centre= identisch, bzw. ist capital= ein Spezialfall von
admin_centre= - für hohe admin_level=  ist capital evtl. eine
Übertreibung.

Zudem konnte ich keine Wiki-Beschreibung für diese Art Relation finden,
sie ist also etwas exotisch - es gibt hingegen eine Beschreibung für
type=country, die auch capital= als Rolle verwendet.


@Tim / wiwosm stuff
Am Beispiel von Deutschland meine ich erkannt zu haben, dass der
admin_centre= Knoten der Grenzrelation mit in die Darstellung wandert. 
Wertest Du die Rollen aus?  Oder wird einfach jeder Knoten, der Teil der
Relation mit dem wikipedia= Link ist, benutzt?  Falls Du die Rollen
auswertest:  suchst Du nach type=state Relationen, die in Verbindung mit
evtl. Grenz-Relationen stehen?


Ich sehe keine Notwendigkeit für type=state Relationen, wenn
admin_centre in MP-Grenzrelationen erlaubt sind.  Zudem ist über die
Angabe des admin_level= auswertbar, ob es sich um country, state, etc.
handelt.  Letzteres ist auch im Wiki dokumentiert.

Gibt es Stimmen, die eine type=state Notwendigkeit sehen?  Falls ja,
weshalb?


Gruß,
Christian



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

Re: [Talk-de] Massen-Edits, automatische Edits, mechanische Edits

[Christian Müller]

Dazu hatte jemand vor kurzem mit der Analogie zur ortsüblichen
Bekanntmachung eine ganz potente Meinung.  Wenn an zwei Orten der Welt
unterschiedliche Lösungen entstehen, deren Ähnlichkeit erst spät erkannt
wird und dann zusätzlich der Wunsch nach Vereinheitlichung aufkeimt, ist
es zwar aufwendig, aber nicht unmöglich, diese Vereinheitlichung zu
einem späteren Zeitpunkt unter Beteiligung beider Parteien zu koordinieren.

Solange niemand schematische Ähnlichkeiten im Tagging zweier Communities
vereinheitlichen will oder überhaupt auch nur sieht, bestünde demnach
auch kein Handlungsbedarf.

Bzgl. Demokratie - der Ursprung des Wiki-Konzepts an sich geht auf die
Idee einer Beteiligung aller zurück - das sich dennoch nicht alle Mapper
daran beteiligen, bzw. parallel dazu alternative, eigenständige Lösungen
entwickeln, sind Formen von Freiheit und Pluralismus, die imho für ein
lebendiges Community-Projekt notwendig sind.  Bei der oft als
Schwesterprojekt wahrgenommenen Wikipedia, hat die Auffassung, diese
Dinge seien abkömmlich, teilweise dazu geführt, dass die
zwischenzeitlich gelobte, hohe Verständlichkeit der Artikel für
jedermann (*) dem Club der Perfektionisten zum Opfer gefallen ist. 
Unabhängig davon, welcher Gruppe man sich aktuell zugehörig fühlt,
braucht es imho die Einsicht, dass geistiger Reichtum auf der Akzeptanz
aller innerhalb eines Community-Projekts beruht.  Das dürfte auch ein
Teil dessen sein, was die Flut aktueller Neulinge von osm erwartet.

Die Neugier der Leute, die sich aus freien Stücken bei OSM registrieren
und dann daran partizipieren, durch vorgetäuschte, rigide Strukturen und
Aussagen á la das haben wir schon immer so gemacht zu bremsen, halte
ich für einen Fehler.  Tautologien der Form das ist so, weil es so ist
können allenfalls Doku geistiger Verarmung sein. (Mindestens braucht es
plausible Erklärungen, wenn sich OSM weiterentwickeln soll.)

Da wir alle Menschen sind, kann das nur ne Richtschnur sein, klar und
ich entschuldige mich ausdrücklich bei denen, die jegliche Form von
Idealismus ablehnen, weil sie mit anderen -ismen beschäftigt sind ;-)


Gruß
Christian


Am 25.04.2012 16:35, schrieb Martin Koppenhoefer:
 Noch ein Punkt, der hier bisher nicht zur Sprache kam: mit
 Demokratie hätten wir auch angesichts der Verteilung der Mapper ein
 starkes Übergewicht der Deutschen. Die kennen aber vor allem
 Deutschland, und nicht alles, was für Deutschland gilt, lässt sich
 auch ohne weiteres auf die restliche Welt übertragen.

 Gruß Martin

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



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

Re: [Talk-de] Massen-Edits, automatische Edits, mechanische Edits

[Christian Müller]

Ist zwar OT,
aber hier hatte ich noch eine Referenz abladen wollen.


 .. der Artikel für jedermann (*) ..

(*) Wer von euch eine Affinität zum Theater hegt, dem sei das
gleichnamige Stück von Hofmannsthal empfohlen.


Gruß
Christian

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

Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)

[Christian Müller]

Am 23.04.2012 23:29, schrieb Tirkon:
 Von welcher Meldung sprichst Du konkret?
 In der Abteilung Relationen wird jede betroffene Relation mit dem
 Zusatz (unvollständig) versehen. Das veranlasst zum Nachzuladen,
 womit es verschindet. Es ist demnach ein Kürzel für unvollständig
 geladen. 

 Inzwischen achte ich darauf, dass nachgeladen wird, was natürlich im
 Rahmen der Zunahme von Relationen immer mühevoller wird.
Besonders dann, wenn die Geschichte rekursiv wird - also das Nachladen
zur Aufnahme neuer, unvollständig geladener Relationen in die
Relationsliste führt..


 Denn JOSM hat
 nach umfangreichen Edits etwas von der ID einer solchen Relation
 gefaselt und dann das Hochladen komplett verweigert. Die Arbeit war
 somit für den A. Ein Fall ist mir noch erinnerlich, wo ich Punkte
 gemergt habe. Eventuell gehörte einer davon zu solch einer Relation.

Das passiert mir auch häufig, wenn ich nicht darauf geachtet habe, dort
nachzuladen, wo Punkte außerhalb der ursprünglich geladenen
Bereichsgrenzen liegen.  Mit Nodes, die komplett innerhalb von geladenen
Bereichen liegen, sollte das, auch beim Mergen, nicht passieren..


Gruß
Christian


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

Re: [Talk-de] Massen-Edits, automatische Edits, mechanische Edits

[Christian Müller]

Am 25.04.2012 20:40, schrieb Martin Koppenhoefer:
 Wenn es um tags und deren Bedeutung geht, dann ist das hat schon
 immer dies bedeutet durchaus das, was vor allem zählen sollte. Die
 Bedeutung der tags ist die, welche die Mapper ihnen zuschreiben. Es
 funktioniert aber nicht, nachträglich einem tag eine einschränkendere
 Bedeutung zuzuschreiben, als er bisher hatte (z.B. aus einem
 allgemeinen tag für einen Weg, der laut Doku für Fahrradwege und
 Fußwege genutzt werden soll, einen Trampelpfad zu machen).

Ja, da bin ich bei Dir - dennoch sollten wir Neulinge hören, denen
Ungereimtheiten und/oder Widersprüche in den Beschreibungen des Wikis
eher auffallen, als den eingesessenen.  Sie sorgen evtl. auch für die
entsprechende Motivation, Teile neu zu überdenken und ggf. zu
präzisieren, wo es Sinn macht.


 Was es kompliziert macht: In manchen Fällen widerspricht das Wiki auch
 dem, wie viele Mapper einen tag sehen (z.T. auch, weil sich das Wiki
 ständig ändert, und manche Änderungen und Präzisierungen auch
 inkompatibel mit der de fakto Nutzung in der Karte sind, in anderen
 Fällen ist die Doku auch lange Zeit so unvollständig gewesen bzw.
 immer noch, dass sich verschiedene Mapper verschiedenes darunter
 vorgestellt haben).

Setzen wir unsere Hoffnungen dahingehend auf das Wiki-Cleanup-Projekt
und deren Kommunikationsfähigkeiten ;-)


Gruß
Christian


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

Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)

[Christian Müller]

Martin Koppenhoefer dieterdre...@gmail.com schrieb:

Am 22. April 2012 18:08 schrieb Christian Müller cmu...@gmx.de:
 Am 22.04.2012 14:47, schrieb Tirkon:
    Multipolygon - zu deutsch etwa viele Vielecke


diese Übersetzung greift zu kurz, es sind Vielecke (eingeschlossen
sind Dreiecke aufwärts), die aus mehreren Umrissen und/oder
Umrissteilen bestehen.

Das ist keine Übersetzung mehr, sondern eine Erklärung.


 Auch eine nicht geschlossene Linie kann als ein Polygon aufgefasst
werden,
 der Wortbedeutung nach.  Hilfsweise kann man sich eine Linie zwischen
 (offenem) Anfangs- und Enpunkt denken.


-1, das bringt uns in OSM nicht weiter sondern sorgt nur für
Verwirrung und ist ggf. auch falsch: wenn solche offenen ways in der
Summe einen geschlossenen Way (und damit je nach Tagging ein Polygon)
ergeben, dann ist die Summe der Polygone, die sich durch einzelnes
Schließen der offenen ways jeweils ergeben, noch lange nicht daselbe
Polygon.

Das hat auch niemand behauptet.  Dennoch kann man jeden offenen Streckenzug mit 
mehr als einer Ecke der Wortbedeutung nach als Vieleck auffassen.  Das eine 
Aneinanderkettung ein neues Polygon bildet, ist implizit klar.  Verwirrend für 
den OP empfinde ich daher deine Antwort.


Im Extremfall (lauter Segmente mit jeweils nur 2 nodes) kann das
Multipolygon durchaus valide sein, die einzelnen Teile sind aber
trotzdem keine Polygone (da es Zweiecke nicht gibt).

Das ist falsch.  Schau Dir

de.wikipedia.org/wiki/Polygon

an.  Streng genommen ist sogar der Punkt eine Ecke.


kann man zwar (unvollständig interpretiere ich als unvollständig
geladen), davon ist aber meistens abzuraten, weil die Gefahr, Dinge
zu zerstören, groß ist.

Finde ich nicht, es funktioniert hervorragend.  Evtl. braucht man etwas Übung, 
aber das gilt für so ziemlich alles - insbes. wenn z.B. Elemente unsortiert 
vorliegen.   Es gibt aber viele Situationen in denen das extrem hilfreich ist.


 Momentan hässlich ist, dass der Editor versucht, unvollständig
geladene
 Flächen zu rendern - das geht i.d.R. schief und sieht unschön aus -
es weist
 aber nicht auf Fehler in den Daten hin.


es weist darauf hin, dass dort etwas unvollständig geladen ist, und
nach Möglichkeit diese Daten nachgeladen werden sollten, m.E. ist das
ein Feature.

Das ist eine Geschmackssache.  M.E. sollten Grafikfehler auf echte Fehler in 
den Daten hinweisen, nicht darauf, dass ein Datensatz nur unvollständig geladen 
ist.  Außerdem lenkt das ganze ab - es ist u.U. nicht nötig, Daten für einen 
bestimmten Edit nachuladen, aber aufgrund der Grafikfehler beschäftigt sich ein 
Mapper mit dem iterativen Nachladen sämtlicher MP, bis alles hübsch ist.

Da es eine Geschmackssache ist, wird es konfigurierbar sein, so wie die Option, 
nur die Außenlinie von Flächen zeichnen zu lassen.


Gruß
Christian

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

Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)

[Christian Müller]

Am 22.04.2012 14:47, schrieb Tirkon:
Wenn ich einen Umring teile, so sind diese Teile keine geschlossenen 
Linien und somit kein Polygon mehr. Wo kommt also die Kette von 
Polygonen her? Möchtest Du einen Staat in Flächenteile (Polygone) 
zerlegen, um diese dann zu vereinen (Kette von Polygonen)? Könntest 
Du das erläutern? 


Ich habe ihn so verstanden:

normale Polygone - ein geschlossener Weg
Multipolygone - mehrere, offene Polygone, die aneinandergereiht 
einen geschlossenen Weg ergeben


Multipolygon - zu deutsch etwa viele Vielecke


Auch eine nicht geschlossene Linie kann als ein Polygon aufgefasst 
werden, der Wortbedeutung nach.  Hilfsweise kann man sich eine Linie 
zwischen (offenem) Anfangs- und Enpunkt denken.  Normale Polygone sind 
nur ein Sonderfall von Multipolygonen, solchen, die nur ein Mitglied in 
der Rolle outer haben - den geschlossenen Weg.  Mehr Details siehe


http://wiki.openstreetmap.org/wiki/DE:Relation:multipolygon


Mir fallen folgende Möglichkeiten ein, eine Staatsgrenze zu erfassen:

- ein geschlossener Weg
- mehrere offene Wege (bzw. Polygone) als outer innerhalb eines MP
- diese können von Bundeslandgrenzen recyclet worden sein
- oder eine eigenständige Näherung darstellen
- mehrere Relationen als outer innerhalb eines MP
- jede Teilrelation enthält dann mehrere offene Wege (bzw. Polygone)

Letztere Variante wird für die Relation mit der ID 1.111.111 verwendet.  
Die Teilrelationen sind jeweils zusammenhängende Abschnitte der 
Gesamtgrenze.  Je Abschnitt werden genau die offenen Wege gruppiert, die 
an genau einen Nachbarstaat grenzen, siehe


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



Zudem meckert JOSM bei unvollständigen Relationen. Dabei wird man im
Unklaren gelassen, was nun passiert, wenn man nicht nachlädt und
dennoch editiert. Also lädt man vorsichtshalber doch nach. Der Vorteil
ist also nur ein theorethischer.


Nein, er ist praktischer Natur - Du kannst auch eine unvollständige 
Relation editieren und Elemente hinzufügen.  Von welcher Meldung 
sprichst Du konkret?


Momentan hässlich ist, dass der Editor versucht, unvollständig geladene 
Flächen zu rendern - das geht i.d.R. schief und sieht unschön aus - es 
weist aber nicht auf Fehler in den Daten hin.  Entweder lädt man die MP 
komplett, dann werden sie auch richtig angezeigt, oder man nutzt die 
Option Flächen nicht rendern in den Einstellungen.  Evtl. ändert sich 
dieses Verhalten in einer zukünftigen Version von JOSM.



Gruß
Christian

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

Re: [Talk-de] Massen-Edits, automatische Edits, mechanische Edits

[Christian Müller]

Am 22.04.2012 00:46, schrieb aighes:
Du willst jetzt nicht ernsthaft behaupten, dass an den 
proposal-Prozessen (und deren Abstimmung) mehr Leute beteiligt sind 
als talk-de oder das deutsche Forum lesen?


Zumal ich denke, dass man mit dem Kreis der Community diskutieren 
sollte, den die Änderungen betrifft. Und wenn es um Änderungen 
innerhalb von Deutschland geht, dann sollte das auch in der deutschen 
Community diskutiert werden und die trifft man hier oder/und im 
deutschen Forum.


Denkst Du, dass jeder der in D mappt, auch Mitglied auf talk-de ist / 
sein will?  Es gibt halt mehrere Communitys - der harte Kern, der auf 
talk-de zu finden ist, und eine größere, die Mapper einschließt, die 
z.B. wirklich nur mappen.  Man kann noch weiter denken und Leute 
einbeziehen, die etwa fleißig auf OSB beitragen.  All dies sind Leute, 
die nicht die Energie und/oder Zeit haben, Skripte zu schreiben, bzw. 
ihr veto einzulegen, in Momenten in denen sie es müßten.  Sie sind über 
talk-de nicht erreichbar - und vermutlich auch nicht über das Wiki, 
obwohl dort die Wahrscheinlichkeit, sie zu erreichen evtl. höher ist, 
wenn sie es gelegentlich besuchen.  Eine Abstimmung auf talk-de sollte 
man damit nicht ohne weiteres als Community-Konsens verkaufen, auch 
nicht, wenn es nur um den dt. Teil geht..



Gruß

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

Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)

[Christian Müller]

Am 21.04.2012 19:41, schrieb Walter Nordmann:

Wolfgang-4 wrote

Bei Landkreisen sind normale Polygone noch handhabbar, bei Staatsgrenzen
teilweise nicht mehr. Da macht es Sinn, die Umringe in eine Kette von
Polygonen zu teilen, die nicht jeder immer laden muss. Das leistet das
Multipolygon.


jo, ganz deiner Meinung.

Schau dir mal diese Relation an:
http://www.openstreetmap.org/browse/relation/111
www.openstreetmap.org/browse/relation/111


Wenn type=boundary und type=multipolygon das gleiche sein sollen (vgl. 
[1]/[2] und div. Auffassungen der Liste), ist es ein herrliches Beispiel 
für die Verwendung verschachtelter Multipolygone:


Alle Elemente in der outer-Rolle sind Relationen.  Laut Definition [2] 
ist das kein gültiges Multipolygon, aber teilweise die Umsetzung dessen, 
worauf ich mich mit den Termini Flächenlinks und -netzwerk bezog.


Wenn eine Landesgrenze in genügend viele Teilschnipsel zerlegt wird, 
steht auch dieser notwendigerweise eine ähnliche Erfassung bevor.  
Gleiches gilt für andere genügend große Gebiete, wie z.B. den Harz, wenn 
die Grenze nicht separat sondern über die Einzelflächengrenzen der 
landuses und roads erfasst wird.


Umgehen ließe sich das nur, wenn man eine höhere Unschärfe in längeren 
Grenzen akzeptiert, also nicht die detailierten Grenzen durch Ansammlung 
recyclet, sondern separate, ungenauere osm-ways nutzt, die eine 
Annäherung ans Detail darstellen.  Als Fläche ließe sich relation 
111 jedenfalls mit aktuellen Tools (JOSM, etc.) nicht anzeigen, weil 
es kein gültiges Multipolygon ist - wenngleich es das IMHO sein könnte - 
die Verschachtelungstiefe liegt bei 1.



Gruß
Christian

[1] http://wiki.openstreetmap.org/wiki/DE:Relation:boundary
[2] http://wiki.openstreetmap.org/wiki/DE:Relation:multipolygon

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

Re: [Talk-de] Massen-Edits, automatische Edits, mechanische Edits

[Christian Müller]

Am 21.04.2012 20:43, schrieb Frederik Ramm:

[...]

Wiki-Links:

http://wiki.openstreetmap.org/wiki/Mechanical_Edit_Policy
http://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct
http://wiki.openstreetmap.org/wiki/Import/Guidelines

Im konkreten Fall mit den type=boundary-Relationen werde ich nichts 
unternehmen. Das ist aber nicht im geringsten ein Freibrief fuer Andre 
oder andere, sowas in Zukunft oefter zu machen. Bitte bringt Euren 
Mit-Mappern den Respekt entgegen, vor solchen Aktionen mit ihnen zu 
sprechen.


+1  Ich fand besonders gut, dass Du anhand von nachvollziehbaren 
Beispielen (die Abschnitte in runden Klammern) argumentiert hast, 
weshalb diese Regeln vergeben werden / wurden.  (Da behaupte nochmal 
einer, Text in runden Klammern sei überflüssig.)


Schwierigkeiten sehe ich aber bei der Umsetzung.  Schließlich wird die 
mailing liste nur von einem sehr kleinen Teil Aktiver gelesen, der nicht 
repräsentativ ist.  Wo soll eine Entscheidung, die auf der Liste dadurch 
entsteht, dass es entweder Widerstand gegen eine Idee gibt, oder nicht, 
dann als eine Community-Entscheidung wahrgenommen werden?


Prinzipiell müsste jede Entscheidung zu automatisierten Edits den 
Proposal-Prozess im Wiki durchlaufen - das bedeutet Aufwand.  Wiki-Seite 
schreiben, ein halbes Jahr Kommentare abwarten - voten.  Und dieser 
Prozess is by no means perfekt.  Je nach Jahreszeit oder 
Weltwirtschaftslage (bitte lachen sie jetzt) ist dann mal die 
erforderliche Masse, damit dieser Prozess funktioniert da, oder nicht.


Wenigstens einen kleinen Kreis vor wirklichen Massen-Edits zu 
informieren, ist besser als ein Alleingang, aber Community im Sinne 
aller aktiver Mapper kann das nicht werden, dazu müsste diese Liste von 
mehr Mappern getrackt werden.  Da ist es dann vielleicht doch besser, 
wenn der Skripteschreiber ein paar Änderungsübersichten ins Wiki stellt 
und, insofern sich einer beschwert, mit einem zügigen Revert reagiert, 
anstatt das als Kollateralschaden hinzustellen.  Eine Ankündigung oder 
wenigstens Dokumentation im Wiki ist in jedem Fall hilfreich.  Bei 
heißen Meinungsverschiedenheiten kann warten einen edit-war vermeiden, 
diskutiert man später nochmal darüber, findet sich vielleicht eine 
Lösung - evtl. sitzen dann sogar ein paar andere Mapper an dem Problem..



Gruß
Christian



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

Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)

[Christian Müller]

Am 20.04.2012 03:14, schrieb Martin Koppenhoefer:

Viel einfacher für Mapper und Datenverwerter sowohl beim Anlegen als
auch für die zukünftige Pflege bei Daten im Vergleich zu einer
site-relation als bunte Mischung aller möglichen Elemente und
Bestandteile ist ein schlichtes Polygon, das die Gesamtfläche
beschreibt. Bei umfriedeten Grundstücken kann man z.B. einen (im
einfachsten Fall) way für  Zaun/Mauer haben, der dann als outer einer
Multipolygon-relation dient, die das Gesamtareal beschreibt. Alles
Darinliegende (Schloßteich, Blumenrabatte, Mülltonnen und
Hundekottütensp...) ist dann automatisch erstmal Bestandteil, sofern
man es nicht explizit als inner way wieder ausschließt, eine Site
braucht man dazu nicht. Ich würde in die site (falls man sie überhaupt
benötigt für das, was man abbilden will) dann auch nicht unbedingt
alle Einzelteile reintun, sondern dieses Gesamtobjekt. Für so was wie
die Teiche in einem Schloßpark würde ich keine eigene site-Relation
anlegen.

Die von Dir beobachtete Verschachtelung, die Du gerne mit Relationen
abbilden willst, ergibt sich bereits geometrisch aus den Daten, auch
ohne jegliche Relation.


Das sie implizit durch mehrfach als Ringelemente verwendete ways 
vorhanden ist, war mir klar - das ist aber dennoch nicht das gleiche.  
Ich habe das Beispiel mit den Kreisgrenzen gebracht - für eine komplett 
innenliegende Kreisgrenze innerhalb eines Landes ist der Flächenbezug 
zwar herstellbar, aber ohne explizite Sammelrelation nur mit 
rechnerischem Aufwand.  Der Unterschied nochmal dargestellt anhand des 
Schlossparks:


Sammelvariante:
Eine Anfrage nach den Teichgeometrien innerhalb des Schlossparks 
ist durch lookup in die Relation zu lösen.


Boundary-Only-Variante:  (also nur die outers des Schlossparks)
Man benutzt die Grenze des Schlossparks zum Verschneiden und sucht 
sich in den verbleibenden Daten die Teiche raus.




Bezogen auf einen kleineren Park ist der Aufwand für beide Varianten 
sicher vernachlässigbar.  Für ein größeres Gebiet ergeben sich mit der 
Sammelvariante aber Vorteile - da man nicht verschneiden muss.  Einen 
gedachten expliziten MP-Baum zu crawlen und alle Teilflächen ohne 
geometrische Berechnung zu ermitteln, dürfte abhängig vom Anwendungsfall 
die bessere Variante sein - manche Anwendungsfälle werden durch ein 
solches Netzwerk evtl. praktisch erst möglich.  Es gibt natürlich auch 
Probleme: z.B. könnten die Relationen schlecht gepflegt sein und man 
erwischt nicht alle Ergebnisse, die man mit einem Verschnitt erhalten 
hätte.  Andererseits könnte ein Verschnitt sehr komplex werden - wenn 
das MP aus mehreren Einzelflächen besteht, also mehrere Verschnitte 
berücksichtigt werden müssen.


Mir ging es darum, aufzuzeigen, dass egal wie man das Kind nennt - 
type=collection, type=site, type=multipolygon - im Endeffekt über den 
Flächenbezug gesprochen wird.  Ich habe jetzt nicht nachgeschaut, aber 
ich schätze Du findest Sammelrelationen aller Kreisgrenzen pro 
Bundesland - sie bilden genau das ab, was auch ein nestedMP abbilden 
würde.  Gleiches gilt für beliebige Sammelrelationen, die Flächen auf 
die ein oder andere Weise sammeln und taggen.   Momentan lungern die 
alle mehr oder weniger zusammenhangslos in der DB - würde man sich auf 
ein paar Regeln für die Verschachtelung einigen, könnten die alle 
mittels nestedMP verlinkt bestehen.




Was Du als schlichtes Polygon beschreibst, ist das, was übrig bleibt, 
wenn man die Flächenlinks (nachgeordnete MP-Mitglieder) innerhalb des 
gedachten 6. MP meiner letzten mail entfernt.  Der Zusammenhang zu den 
Kindern ist dann nicht mehr explizit erkennbar, allenfalls implizit 
geometrisch.  Der Komplexitätsgrad aller Relationen ist dann gleich, 
sie sind alle gewöhnliche Multipolygone.


Erhält ein Datenverwerter (e.g. renderer) diese MP, überlappen die 
Flächen nun - entweder der Schlosspark wird als monotone Fläche opaque 
über die Einzelflächen gezeichnet, oder darunter.  Für einfache Sachen 
(etwa buildings on top of landuses) kriegt ein Renderer das per Regel 
hin, ob das aber für jeden denkbaren Fall von (sinnvoller) 
Verschachtelung der Fall ist?  Die Verschachtelung entsteht schon 
implizit durch gewöhnliche MP.


Um es festzuhalten:  Die Überlappung kann dadurch entstehen, dass je 
nach Sicht auf eine Einzelfläche,
sie entweder ein Loch innerhalb einer anderen Fläche (sie wäre dann 
nur deren Grenze),

sie selbst eine Gesamtfläche,
sie eine Teilfläche von einer oder mehrerer größerer Flächen
darstellt.


Je nachdem, welches Thema ein Renderer hat, müssen nicht alle Sichten 
auf diese Einzelfläche dargestellt werden.  Wären Flächenlinks innerhalb 
der Relation vorhanden, könnte ein Datenverwerter allerdings durch die 
schiere Anwesenheit von Flächenlink-Mitgliedern erkennen, ob mehr Detail 
vorhanden ist.  Ohne die Geometrie zu berechnen, ließe sich entscheiden, 
welche Flächen dann beispielsweise nicht opaque bzw. nur mit Namen 
gerendert werden.  Zugegeben, das 

Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)

[Christian Müller]

Hallo Wolfgang,


Am 20.04.2012 12:04, schrieb Wolfgang:

Ich glaube, an dieser Stelle missverstanden zu sein. Solange es nur um
zusammengehörige Flächen gleichen Typs geht, reicht das Multipolygon
völlig aus. Ich will nicht Multipolygone durch Sites ersetzen, sondern
verhindern, dass
- das Multipolygon mit Elementen verwässert wird, die mit der Fläche
nichts zu tun haben (place etc) und
- die Flächenberechnung / Darstellung im Multipolygon konzentrieren
(wenn sie komplizierter ist als ein einfacher Umring)


Weshalb verwässern?  Anhand der inner/outer Rolle, die nur durch ways 
besetzt werden darf, ist doch klar, was zur Flächenberechnung 
herangezogen wird.  Weshalb fürchtest Du die Aufnahme weiterer Elemente 
in anderen Rollen?  Oder geht es Dir nur um die Größe, auf die ein MP 
dann u.U. anwachsen kann?




Die Seefläche wird nicht als Loch im Park definiert, weil sie 1. zum
Park gehört und 2. üblicherweise der Renderer damit klar kommt, die
Wasserfläche hat insofern Vorrang.


Die Zugehörigkeiten fasse ich genauso auf wie Du - damit sind wir bei 
der Überlappung der Flächen angekommen.  Das Beispiel wird von den 
jetzigen Renderern sicher erwartungsgemäß priorisiert und richtig 
dargestellt.  Spätestens wenn sich landuse=* und leisure=* MPs 
überlappen, kann ich mir aber nicht mehr vorstellen, wie eine 
Renderregel das sinnvoll priorisieren will - Nehmen wir an ein kleinerer 
Stadtpark überlappt auf den Rand einer großflächigeren Wiese.  Es ist 
durch geographische Gegebenheit zu erkennen, dass die Überlappungsfläche 
je nach Sichtweise beiden MP zugeordnet werden kann, also erfasst ein 
OSMler das auch so - in klassischen Karten würde man vermutlich im 
Überlappungsgebiet schraffieren oder punkten.  Da das ganze sehr 
theoretisch ist, lohnt eine Fortsetzung an dieser Stelle vermutlich erst 
mit einem echten Beispiel.  Belassen wir es also dabei..




Wenn jemand eine Statistik aller Rosenbeete in den
Schlossparks des Landes erstellen will, dann muss er eben abfragen,
welche Beete sich räumlich in einem solchen Park befinden.
- Etwas in der Richtung hatte ich im Hinterkopf.  Für komplexe 
Statistiken ist der Rechenaufwand über die räumlichen Abfragen evtl. 
unnötig hoch und wenn es viele Anwender gibt, die unabhängig voneinander 
die gleichen Statistiken erstellen, verschwendet man Energie ;.-)  Ist 
es nicht gerade für die Erstellung solcher Statistiken von Vorteil, wenn 
Schachtelungszusammenhänge explizit in den Relationen wären?  Klar 
können wir uns auch von diversen Rechenzentren abhängig machen, aber 
eine intelligente Lösung ist das nicht, klingt eher wie brute force..




Leider sind verschachtelte MP-Relationen (nestedMP) unpraktikabel,
wenn es um die Berechnung der Fläche geht, die sich aus den
Einzelflächen der Kinder und Kindeskinder (..) ergibt.  Schließlich
sind nur die outer/inner Mitglieder der Kinder und Kindeskinder (..)
interessant, die tatsächlich einen Beitrag zu Außen- oder
Innenringen des nestedMP liefern.  Ab einer bestimmten
Schachtelungstiefe wird die
Grenzbestimmung daher unbeherrschbar - um die Flächengrenze eines
nestedMP zu ermitteln, müssten alle Blätter des MP-Baumes durchsucht
werden, also alle Relationen, die dann tatsächlich way-members als
Mitglieder haben und nicht selbst ein nestedMP sind.  Je tiefer
dieser Baum, desto höher die Wahrscheinlichkeit, dass es mehr
irrelevante members als relevante gibt.

So ganz kann ich deinen Ausführungen nicht folgen. Im Prinzip ist das
Multipolygon überraschend einfach zu berechnen und gleichzeitig
geschickt aufgebaut.


Es ging um (gedachte) nested MP, in denen MP Mitglieder anderer MP sind 
- das ist bisher nicht erlaubt.  Für die gewöhnlichen MP, stimme ich Dir 
zu - schicke Sache.  Mir fällt auf, dass der Terminus geschachtelte MP 
auch für die durch alternierende inner / outer Ringe konstruierten MP 
verwendet wird - von diesen habe ich ausdrücklich nicht gesprochen - mir 
ging es um die Verschachtelung von Flächen verschiedenen Typs, weil sie 
logisch Teil einer oder mehrerer anderer Flächen sind.




[...] Das heißt auch, dass nur die Umringe
als Typ outer definiert werden dürfen, die tatsächlich vom Typ des
Multipolygons sind.


Ich verweise dann einfach immer auf 
http://wiki.openstreetmap.org/wiki/DE:Relation:multipolygon - spart 
Tipp-Arbeit ;-)



Für Grenzen bietet sich das Multipolygon an - nicht um irgendwelche 
inner zu definieren, sondern weil es möglich ist, das outer aus 
einer größeren Anzahl von (nicht geschlossenen) Polygonen zu 
definieren, die zusammen einen geschlossenen Umring ergeben. Ähnlich 
wie bei der coastline hat es gewisse Vorteile, nicht immer den ganzen 
Umring der z.B. USA laden zu müssen. Die Landesgrenze ist ein MP, die 
Kreisgenzen jeweils auch. Wer die Hauptstadt, Verwaltungszentrale oder 
was auch immer da rein bringen will, kann das dann über die Site 
machen. Members sind dann das Multipolygon mit der Grenze und der 
place-Node der Zentrale. Land und Kreise untereinander brauchen 

Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)

[Christian Müller]

Hallo nochmal,



noch ein Nachtrag - für Statistiken, welche die implizite Variante der 
Flächenbezüge als Grundlage nutzen, wäre zwar auch ein Cache für 
aufwendig errechnete Ergebnisse denkbar - für einen solchen existieren 
aber m.W. in und um OSM weder Standards noch die Möglichkeit ihn 
sinnvoll zu teilen / publishen.  Gibt es grob gedacht eine Kreuzung aus 
Nominatim und dem Relation Browser für das Browsen von Flächenbezügen? 
Evtl. gibt es da schon Ansätze in OSM Inspector oder anderen Validatoren.


Ist die Overpass API momentan die einzige Möglichkeit Daten-Queries zu 
tätigen, oder gibt es noch andere Dienste, die evtl. zusätzlich, aus den 
OSM-Daten abgeleitete Daten bereitstellen?  Die MapQuest-Dienste sind 
mir geläufig.



Gruß und Dank,
Christian



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

Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)

[Christian Müller]

Du kannst mit dem Planet Dump die Daten in jede DB stopfen, wenn Du dir 
die Mühe machst einen Converter zu schreiben.


Nochmal:  Es geht nicht darum, alle automatisch 
ermittelbaren/herstellbaren Flächenbezüge, manuell zu erfassen, sondern 
nur die, welche dem Mapper sinnvoll erscheinen.


Der Optimierungswille den Du ansprichst, hat nicht nur etwas mit DBs zu 
tun.  Warum gehen davon eigentlich alle aus?  Nicht immer stecken die zu 
verarbeitenden Daten in einer fetten DB, die bereitwillig rechnet.  Gäbe 
es die Flächenbezüge in den Daten wären z.B. auch billige JavaScript 
Hacks denkbar, die dann client-seitig laufen, anstatt einen Server zu 
belasten..



Gruß


Am 20.04.2012 14:57, schrieb Ronnie Soak:

Duerfte ich als unbeteiligter Dritter dem OP diesen Link empfehlen:

http://en.wikipedia.org/wiki/Spatial_database

Interessanterweise gibt es keine gute Uebersetzung dafuer und Wikipedia
verlinkt es auch nicht zu einem deutsche Artikel.
Wer den findet, kann ihn ja gerne mal posten.

Ich glaube, die spezielle Eigenschaft dieser Art der Datenhaltung scheint
hier unbekannt, was den merkwuerdigen Optimierungswillen hin zu
'billigeren' Anfragen mit expliziten site-Relationen ausloest.

Ich weiss ehrlich gesagt nicht, ob OSM wirklich so organisiert ist, aber
ich habe es zumindest bisher immer angenommen.

Gruss,
Chaos
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de




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

Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)

[Christian Müller]

Am 20.04.2012 16:19, schrieb Frederik Ramm:

Hallo,

On 04/20/2012 02:54 PM, Christian Müller wrote:
Ist es nicht gerade für die Erstellung solcher Statistiken von 
Vorteil, wenn

Schachtelungszusammenhänge explizit in den Relationen wären?


Als jemand, der mit solchen Fragen staendig in der Praxis umgeht, kann 
ich sagen:


Es ist 100% klar, dass ich mich nie darauf verlassen kann, dass unsere 
Mapper solche Schachtelungen eintragen. (Sie kriegen ja nicht mal 
geometrisch gueltige Polygone hin...)


Liegt vielleicht auch an der elitären Haltung, die man ihnen 
entgegenbringt, will man es erklären (nur so ein Gedanke..).  Ich stimme 
Dir im Inhalt zu, die Form finde ich grauenhaft..  Ist halt leider so.



Ich muss also in jedem Fall, wenn ich jetzt nicht gerade nur Christian 
Muellers Heimatort analysieren will, die geometrische Abfrage 
*zusaetzlich* zu etwaigen explizit modellierten Beziehungen machen.


Daher spart mir die explizierte Modellierung nichts, egal, wie 
schoen sie in der Theorie waere.


Prophetentum ist eigentlich nicht unser Metier, aber ich stimme ein in 
den Kanon, dass OSM vermutlich immer ein Sammelsorium an verschiedensten 
Ausdrucksmöglichkeiten für geographische Sachverhalte bleiben wird.



Gruß
Christian

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

Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)

[Christian Müller]

Am 20.04.2012 16:19, schrieb Frederik Ramm:

Mapper solche Schachtelungen eintragen. (Sie kriegen ja nicht mal
geometrisch gueltige Polygone hin...)


[...]

Oder wir haben zu wenig gute  How To  Vids..  Vielleicht eine Youtube 
Hilfe in JOSM integrieren.  Aber das feature nicht Video2Brain nennen, 
das ist m.W. ne Marke von einem größeren Buchverlag.



Gruß

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

[Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)

[Christian Müller]

Moin,

ich mag in diesem Zusammenhang noch einmal kurz auf das Thema 
Flächennetzwerk zurückzukommen.

Have a fun read..


Am 19.04.2012 13:05, schrieb Wolfgang:
-1 Das Multipolygon sollte rein Fläche bleiben, und Fläche sollte nur 
im Multipolygon erfasst werden. Wer was dazu sammeln will, kann das 
über eine site verbinden. Wieder das Thema Relationen verbiegen. 


Damit würdest Du z.B. sämtliche Parks als type=site Relationen erfassen, 
in denen Du dann die MP der Einzelflächen sammelst.  Aber was ist 
überhaupt eine Einzelfläche?




Betrachten wir beispielsweise einen Schlosspark bestehend aus mehreren 
Teichen, Rabatten, Wiesen, etc. die im Park verteilt sind - das Schloss 
selbst steht auf einem Sockel im Zentrum des Parks.


1. MP - Teiche
2. MP - Rabatten
3. MP - Wiesen
4. MP - Sockel
5. MP - Schloss

Die ersten drei MP werden Löcher haben (alles mit ways in der Rolle 
inner machbar).  Kommen wir zum Park, wir erstellen unsere type=site 
Relation, packen die ersten drei MP hinein und stellen uns dann die 
durchaus interessante Frage, ob das Schloss zum Schlosspark gehört, es 
demnach ebenfalls mit in die Sammelrelation aufgenommen werden sollte.




Bevor wir diese Frage beantworten, stellen wir aber fest, dass mehrere 
der Teiche kleinere Inseln haben, wir splitten also die Teiche in


1.a. MP - Wasserflächen
1.b. MP - Inseln

Man beachte, dass die Löcher lt. MP-Definition nicht zur Fläche gehören, 
also ist (1.a.) nicht das gleiche wie (1.).  Nach deiner Einschätzung 
legen wir also (1.) neu an, als type=site Relation


(1.neu.) type=site - name=Teiche



Möchten wir nun unseren Park zusammenbauen, können wir das auf zwei 
Arten tun:


type=site Mitglieder:
MPs (1.a.) (1.b.) (2.) (3.) ...

type=site Mitglieder:
(1.neu.) + MPs (2.) (3.) ...

Ich tendiere zu letzterer Variante, allerdings enthielte type=site dann 
eine Relation vom gleichen Typ.  Wir beschäftigen uns also mit 
verschachtelten type=site Relationen.




Das wir den Namen von type=multipolygon auf type=site ändern, 
verschleiert IMHO nur die Tatsache, dass auch Flächensammlungen nichts 
anderes sind als Flächen.  Das geht übrigens schon aus der einfachen, 
bisherigen Definition von MP hervor.  Betrachten wir z.B. das zweite MP 
des imaginären Schlossparks - die Rabatten.  Schon dieses kann eine 
(Einzel-)Flächensammlung sein - je nachdem, wieviele Rabatten der Park 
hat.  Die momentane Definition von Multipolygonen erlaubt es uns also, 
mehrere Flächen zusammenzufassen, solange sie gleichen Typs sind, 
sprich, solange der Mapper sie als zusammengehörig empfindet und sie mit 
den gleichen Tags beschreiben kann.


Leider sind verschachtelte MP-Relationen (nestedMP) unpraktikabel, wenn 
es um die Berechnung der Fläche geht, die sich aus den Einzelflächen der 
Kinder und Kindeskinder (..) ergibt.  Schließlich sind nur die 
outer/inner Mitglieder der Kinder und Kindeskinder (..) interessant, die 
tatsächlich einen Beitrag zu Außen- oder Innenringen des nestedMP 
liefern.  Ab einer bestimmten Schachtelungstiefe wird die 
Grenzbestimmung daher unbeherrschbar - um die Flächengrenze eines 
nestedMP zu ermitteln, müssten alle Blätter des MP-Baumes durchsucht 
werden, also alle Relationen, die dann tatsächlich way-members als 
Mitglieder haben und nicht selbst ein nestedMP sind.  Je tiefer dieser 
Baum, desto höher die Wahrscheinlichkeit, dass es mehr irrelevante 
members als relevante gibt.


Bsp.: Kreisgrenzen und Landesgrenze - es gäbe 'zig innenliegende 
Kreisgrenzen, die für die Berechnung der Landesgrenze nicht relevant 
sind - deshalb macht es für die Berechnung der Grenzgeometrie keinen 
Sinn, die Landesgrenze über ein nestedMP mit allen Kreisgrenz-Relationen 
als Mitglieder zu erfassen.  Dennoch interessiert evtl. der Flächenbezug 
der Kreisflächen zur Landesflächen in einem anderen Kontext.  Beide 
Wünsche ließen sich vereinen.




Um auf das Beispiel zurückzukommen:  Ich kann mir auch den gesamten Park 
als Einzelfläche vorstellen, ohne die Grenzen der Rabatten, Teiche, 
Wiesen, etc.  Weil ich das kann, möchte ich den Park auch als 
type=multipolygon anlegen und nicht als type=site (Anm.: type=site 
entspräche einem nestedMP, wenn man daraus die Geometrie der 
Gesamtfläche des Parks ermitteln will).  Um mit der bestehenden 
Definition von MP zu arbeiten, würde ich also alle relevanten Mitglieder 
aus (1.) (2.) (3.) und evtl. (4.) und (5.), je nachdem ob das Schloss 
zum Schlosspark gehört oder nicht, ermitteln und diese in ein neues MP


6. MP - Schlosspark

übertragen.  Das geschieht händisch, nach Ermessen des Mappenden.  Der 
einzige explizite Zusammenhang in OSMs Daten zwischen Schlosspark und 
zugehörigen Teilen (Wiesen, Teichen, Rabatten, etc.) wäre dann über die 
Flächengrenze des Schlossparks ersichtlich - eine komplett innenliegende 
Wiese, die sich keine Grenze mit Flächengrenzen des Schlossparks teilt, 
hätte keinen expliziten Zusammenhang in den Daten.




Geht es nicht um die Geometrie, sondern einfach nur um 

Re: [Talk-de] Massenumbenennung Relationen von Multipolygon in Boundary

[Christian Müller]

Hi,


scheint beides akzeptiert und in use zu sein:

http://wiki.openstreetmap.org/wiki/Relation:boundary


Die Änderung ist demnach nicht falsch, hat aber imho einen zu 
vernachlässigenden Mehrwert.



Gruß


Am 18.04.2012 23:41, schrieb Tirkon:

Moin,

offensichtlich hat jemand hier und möglicherweise in weiteren
Changesets massenweise den Typ von Grenz-Relationen von multipolygon
auf boundary geändert:
http://www.openstreetmap.org/browse/changeset/10934495

Der OSM Inspektor gibt jetzt eine Warnung aus:
http://tools.geofabrik.de/osmi/?view=multipolygonlon=7.56300lat=53.07715zoom=10opacity=1.00overlays=invalid_geometry_hull,duplicate_ways,intersections,intersection_lines,ring_not_closed_hull,ring_not_closed,unconnected_end_nodes,touching_inner_rings_hull,touching_inner_rings,role_mismatch_hull,role_mismatch,duplicate_tags_hull,duplicate_tags,multipolygons_type_is_boundary,type_is_boundary,ways,role_markers,way_end_nodes,way_nodes

Ist diese Änderung von multipolygon auf boundary nun korrekt oder
nicht?

Leider kann ich nicht mit letzter Sicherheit prüfen, ob das wirklich
in diesem Changeset passiert ist. Wenn ich nämlich auf eine der
Relationen klicke und dann die Historie anzeigen lassen möchte, kommt
immer ein Timeout. Ist dieses Timeout nun möglicherweise eine Folge
der derzeitigen Lizenzumstellung/Serverwechsels oder ein Bug? Wo
müsste man diesen Bug melden?


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




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

Re: [Talk-de] ÖPNV-Relationen in OSM

[Christian Müller]

Am 04.04.2012 20:18, schrieb Stephan Wolff:

Moin!

Am 03.04.2012 16:23, schrieb Christian Müller:

Bei der Vielfalt der Linienfahrpläne in the wild lässt sich das
eigentlich auch nur lösen, wenn die kompletten Fahrpläne erfasst werden

bus_stop: collection_times pro Linie pro Richtung

Beispiel:
1. Relation (nur Hp-Mitglieder gelistet)
Hp1 in der Rolle 07:00, 08:00, 09:00, 12:00, 13:00, 15:00, 18:00, 19:00


Das können wir allgemein nicht erfassen und pflegen.
Allenfalls für Fernbusse, spezielle Züge oder Fähren mit 1-3 (evtl. bis
5) Abfahrten pro Tag wären einzelne Abfahrtszeiten in OSM machbar.
Ansonsten wären schon die Betriebszeiten und der Takt bzw. die Zahl der
Fahrten pro Tag sehr hilfreich.


Alle angesprochenen Merkmale sind Aggregate aus dem zugrundeliegenden 
Fahrplan - für Linien, die keine starke Regelmäßigkeit/Struktur 
aufweisen, ist eine Aggregation nutzlos.  Damit lässt sich also auch 
keine allgemeine Empfehlung für die Erfassung solcher Werte aussprechen.


Der Takt z.B. bringt höchstens etwas für innerstädtische Linien - im 
städtischen Randgebiet ist eine Abstraktion der stark variierenden 
Linienvarianten oft nicht sinnvoll.  Ich sehe auch nicht, welchen 
Mehrwert die Zahl der Fahren pro Tag bringen soll.  Bei den 
Betriebszeiten besteht die Möglichkeit, dass für manche Linien z.B. der 
letzte Wagendurchlauf ein verkürzter ist, die Linie aber in OSM komplett 
erfasst ist.  Wer einmal den letzten Bus des Tages aufgrund schlechter 
oder falsch interpretierter Information verpasst hat, kann sich 
vorstellen, welche Verwendung die Informationsquelle zukünftig für 
sie/ihn noch findet.  Ich empfinde es daher als nutzlos, 
nicht-statische, durch Mapper selbst aggregierte Informationen von 
Fahrplänen in OSM zu taggen.  Wem es dennoch Spaß macht, go ahead..


In die Annahme, dass wir das allgemein nicht erfassen und pflegen 
_wollen_, hatte ich schon eingestimmt - missing manpower.  Wöllten wir 
es, sollten wir uns auf den Fahrplan stürzen, alles andere bliebe so 
unzulänglich, wie die bisherige Varianten, deren Erfassung und Pflege Du 
m.E. zu recht als mühsam und unbefriedigend genau empfindest.




- manche Linien machen Abstecher, halten aber nicht notwendigerweise
zweimal, während sie den Teil des Pfades durchlaufen


Aber die Abfolge der Haltepunkte wäre doch eindeutig definiert. Wie kann
es falsche Auswertungen geben?


Indem z.B. nicht auf dem Abstecher zurückgeroutet wird, sondern vom 
Router eine andere Route  zur Folgehaltestelle errechnet wird.


4-+
| |
| |
+---23
|
|
1

von 3 nach 4 gibt es mehrere Wege - das Unternehmen, welches den PNV 
betreibt, definiert aber i.d.R. genau eine Route, die der Fahrer nimmt.  
Das Problem ist, dass eine Routing-Engine u.U. nicht nach den gleichen 
Kriterien entscheidet, die das Unternehmen zur Routenplanung verwendet.  
Es ist sogar so, dass die Routenplanung von Unternehmen zu Unternehmen 
unterschiedlich sein wird und verwendete algorithmische Grundlagen nicht 
vorliegen.  Die Identität zum Problem der Bestimmung des kürzesten Weges 
zwischen Haltepunkten ist somit oft nicht gegeben.  Dies trifft 
vermutlich um so mehr zu, je weiter Haltepunkte auf einer Route 
voneinander entfernt liegen.  Via-Knoten können da Abhilfe schaffen, 
aber lägen die dann nicht auch auf den osm-ways die von Veränderung der 
Basisgeometrie betroffen sind?





In der Praxis werden bei Änderungen an den Straßendaten gerade die
streckenbasierten Busrelationen viel zu oft unterbrochen oder nicht
auf die neuen Wege angepasst, entweder weil der Mapper die Relationen
nicht gut genug kennt, keine Lust zur Anpassung hat oder schlicht
Fehler macht. Das finde ich schlimmer, als evtl. mögliche Abweichungen
von der Fahrstrecke.


+1   Ob es besser funktioniert, als die bisherige Mappingpraxis, kann 
nur ein Versuch zeigen.  Solange die Hps angefahren werden, sehe ich 
mögliche Abweichungen vom echten Streckenverlauf auf der ÖPNV-Karte auch 
nur als kosmetisches Problem.  Zumal aufgrund des angesprochenen 
Variantenproblems in den Linienverläufen ohnehin nur die am häufigsten 
verwendete Variante einer Linie in OSM landen wird.


Das beste wäre tatsächlich eine Verknüpfung mit echten Fahrplandaten der 
Verkehrsunternehmen per API.  Wenn sich da in den nächsten Jahren etwas 
öffnet, kann man evtl. auf die Erfassung von ÖPNV-Relationen in OSM ganz 
verzichten.  Ein Mashup enumeriert dann einfach die Linien über das 
angebotene API, holt sich die Haltestellen je Linie, korreliert diese 
mit den bus_stops in OSM, errechnet eine Route und rendert das ganze in 
die ÖPNV-Karte.  Vorstellbar wäre auch, dass man verschiedene Tiles 
(oder Overlay-Tiles) je nach Tageszeit generiert und ausliefert, um die 
Veränderung des Linienverlaufs tageszeitbedingt zu reflektieren.


Ohne API und bei dem momentanen Interesse der Community an ÖPNV bleiben 
wir vermutlich auf dem momentanen Niveau einer eingeschränkt 
genauen/statischen Visualisierung der

Re: [Talk-de] ÖPNV-Relationen in OSM

[Christian Müller]

Am 03.04.2012 02:35, schrieb Stephan Wolff:

Relation in 2 aufspalten.

Wenn es alternativ bediente Teilstrecken sind, dann sollte man die

Das Problem vieler Streckenvarianten derselben Linie wurde oft 
diskutiert aber nie gelöst.


Bei der Vielfalt der Linienfahrpläne in the wild lässt sich das 
eigentlich auch nur lösen, wenn die kompletten Fahrpläne erfasst werden 
- da fehlt aber die manpower.  Prinzipiell kann man daran ständig 
arbeiten, da auch die Verkehrsunternehmen im Ganz- oder Halbjahrestakt 
Anpassungen vornehmen.


Ansonsten kann man die Haltepunkte aus der Sicht von post_boxen 
betrachten, vgl.:


post_box:  collection_times

bus_stop:  collection_times pro Linie pro Richtung

Beispiel:
Morgens, Mittags und Abends wird die Route komplett befahren, Vor- 
und Nachmittags jedoch nur bis zu einem Zwischenstopp

Haltepunkte sind Hp1(Start) Hp2 Hp3(Zwischenstopp) Hp4(Ende)
- es gibt zwei Linienrelationen (eine pro Richtung)

1. Relation (nur Hp-Mitglieder gelistet)
Hp1 in der Rolle 07:00, 08:00, 09:00, 12:00, 13:00, 15:00, 
18:00, 19:00
Hp2 in der Rolle 07:10, 08:10, 09:10, 12:10, 13:10, 15:10, 
18:10, n/a
Hp3 in der Rolle 07:15, 08:15, 09:15, 12:15, 13:15, 15:15, 
18:15, 19:15
Hp4 in der Rolle 07:30, 08:30,  n/a, 12:30, n/a, n/a, 
18:30, 19:30


2. Relation
analog - Hp in umgekehrter Reihenfolge


Grob gedacht:  Nutze Werte in der Art, wie sie für collection_times 
verwendet werden, im Feld Rolle der Haltepunkte pro Relation.  Darüber 
würde effektiv der Fahrplan abgebildet.



Ich hatte auch schonmal darüber nachgedacht, ob nicht die Haltepunkte 
reichen, um den Linienverlauf automatisiert mittels geeigneter 
Routing-Engine ermitteln zu lassen.  Das birgt aber folgende Probleme:


- manche Linien machen Abstecher, halten aber nicht 
notwendigerweise zweimal, während sie den Teil des Pfades durchlaufen
- Linien folgen nicht notwendigerweise dem kürzesten  Pfad (u.U. 
durch Rücksicht auf Anwohnergebiete oder andere Gegebenheiten: 
Straßenausbau, etc.)
- Routing ist _nicht_ stabil:  stellt euch vor, euer Router 
ermittelt automatisiert einen korrekten Linienverlauf, einen Monat 
später macht ein Mapper eine Ergänzung, welche die kürzeste Route 
beeinflusst - schon würde sich die Route der Linie ändern (und 
entspräche demnach nicht mehr dem in der Realität unveränderten Verlauf)


- der Pfad sollte Teil der Relation bleiben, eine Erfassung der 
Haltepunkte reicht nicht aus



Viele Grüße,
Christian

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

Re: [Talk-de] WIWOSM-Projekt ist live

[Christian Müller]

Am 22.03.2012 11:35, schrieb Kolossos:

Am 22.03.2012 09:13, schrieb ThomasB:

@Tim
Das bestehende System wikipedia:de=Title hat auch eine Sprachversion




Falls die Sprachversionen zu einem geografischen Objekt in der Wikipedia 
nicht interwiki-gelinkt sind, gäbe es ja zwei Möglichkeiten


 - zwei wikipedia tags in osm
 - oder Interwiki-Link in der Wikipedia ergänzen

Die erstere Möglichkeit fällt flach, wenn man mittels 
wikipedia=lang:title taggt.  Falls die Frage in der Zukunft gestellt 
wird, empfehlt ihr dann zweiteres Vorgehen?


Manchmal ist es evtl. interessant ein OSM-Objekt mit zwei verschiedenen 
Wiki-Artikeln (der gleichen Sprache) zu verlinken - @Tim:  wie wäre das 
zu taggen, damit WIWOSM dann für beide Artikel die (gleiche) Geometrie 
findet?



Gruß,
Christian

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

Re: [Talk-de] WIWOSM-Projekt ist live

[Christian Müller]

Am 21.03.2012 21:05, schrieb ThomasB:
 Einfach mal so, ohne jemand etwas zu
 sagen das Tagging Schema bei OSM zu ändern, geht nicht. 

+1.  Dennoch, das bedeutet auch, dass man sich mit Vorschlägen auf der
Liste im Detail befasst.  Ich sehe da eine gewisse Müdigkeit.

Dem folgend kann ich mir gut vorstellen, dass nach dem kolossalen Coding
von WIWOSM, die Änderung des Wikis trivial erschien.  Problematisch wird
es, wenn dadurch andere Drittanwendungen brechen, aber ob deren
Maintainer dann durch den Listenpost erreicht werden, bleibt so und so
fraglich.  Zudem ist das Wiki keine Bibel, sondern ein Leitfaden zum
Konsens..

Weiterhin ist [[Talk:*]]  im Wiki dazu da, dort _themenbezogen_
diskutieren zu können, damit die Mailingliste digestable bleibt und
bestenfalls nur noch ein paar links dorthin aufnehmen muss, z.B.:
   
http://de.wikipedia.org/wiki/Konsens#Konsens_als_Ziel_bei_Gruppenentscheidungen

Ich persönlich finde es einfacher und angenehmer im Wiki zu stöbern, als
in den automatisch zusammengestellten Mailing-List-Archives.


Gruß
Christian

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

Re: [Talk-de] Start des deutschen WikiProjekts Cleanup

[Christian Müller]

Am 19.03.2012 07:33, schrieb Ronnie Soak:

Bevor deutsche Uebersetzungen von wichtigen Konzepten und Tags gar
nicht existieren (oder nicht vernuenftig verlinkt sind) brauchen wir
ueber kontroversen beim Inhalt gar nicht diskutieren.


Hi Ronnie,


jo, dem hatte ich in der Form schon zugestimmt.  Vermutlich habe ich das 
Anliegen des Projekts aufgrund der verwendeten Sprache etwas 
missverstanden.  Dennoch bleibe ich auch für neu zu übersetzende Seiten 
auf dem Standpunkt:  Keine Übersetzung ist besser als eine falsche oder 
grob ungenaue Übersetzung.  Gerade für Mapper, die der englischen 
Sprache nicht mächtig sind, und demnach im Falle eines Disputs wenig 
Chancen haben mitzureden, übernimmt der Übersetzende große 
Verantwortung.  Je nach Umfang der Daten, die aufgrund einer nicht 
tragfähigen Übersetzung (was das ist, entscheidet die Zukunft..) in die 
DB wandern, kann das Resultat sein:


- unterschiedliche Interpretation des gleichen (engl.) tags in 
unterschiedlichen Sprachräumen

- Notwendigkeit, Daten umzutaggen


Mir ging es nur darum, darauf hinzuweisen.  Klar muss man die Sache an 
sich voranbringen.



LG
Christian

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

Re: [Talk-de] Start des deutschen WikiProjekts Cleanup

[Christian Müller]

Am 19.03.2012 10:20, schrieb Wolfgang:
Dazu sollte auch die Struktur des Wiki überdacht werden. Ein Anfänger, 
der nicht in diesen Strukturen zuhause ist, hat erst mal ein Problem, 
überhaupt Informationen zu finden. Der nahezu einzige Weg dazu ist die 
Suche nach Stichwörtern. Wenn man aus der text- (Buch-)gebundenen Welt 
kommt, ist man es gewohnt, Inhaltsverzeichnissen folgen zu können.


Hierzu sei erwähnt, dass Software teilweise mit diesen Strukturen eng 
verheiratet ist.  Zum Vorteil der Nutzer existiert in JOSM 
beispielsweise eine kontextgebundene Hilfe:


* F1 auf selektiertem Text im Tag-Dialog, oder
* Rechtsklick  Kontextmenü benutzen, um die jeweilige 
OSM-Wiki-Seite zum Tag aufzurufen


Es spricht natürlich sonst nichts dagegen, neue Zugangswege in diese 
Strukturen zu schaffen.



LG
Christian

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

Re: [Talk-de] Start des deutschen WikiProjekts Cleanup

[Christian Müller]

Hi,


hier meine Übersetzungsbeiträge:

cleanup die Aufräumarbeiten
cleanup das Löschen
cleanup die Säuberung
cleanup die Säuberungsaktion

Quelle: http://dict.leo.org/ende?search=cleanup


- das OSM-Wiki ist _eine_ Ressource für Mapper
- .. taginfo, mailing-list, Stammtisch, etc. sind weitere

- die englischen Wiki-Seiten sind nicht in allen Bereichen 
aussagekräftiger
- teilweise sind englische Wiki-Seiten den dt. hinterher 
(veraltet/obsolet/ungepflegt)
- teilweise gibt es für dt. Einträge aufgrund utnerschiedlicher 
Tagging-Bedürfnisse der Regionen kein engl. Pendant, welches zur 
Übersetzung herangezogen werden könnte


- Ein cleanup kann ich eigentlich niemandem empfehlen, der sich nicht 
unglücklich machen will.  Teilweise sind Wortwahl und Definition der 
Beschreibungsseiten zu Tags in wochenlanger Kleinarbeit auf den 
mailing-listen ausgefochten worden.  Ungeachtet der Sinnhaftigkeit eines 
solchen Prozesses, ist es sicher nicht produktiver, wenn sich nun 
Einzelpersonen daran machen, diese Beschreibungen in einer 
Hau-Ruck-Aktion ohne Abstimmung zu ändern, selbst wenn es sich nur um 
eine Übersetzung der englischen Seite handeln würde (denn Übersetzungen 
sind gerade im Geokontext oft spezifisch und/oder mehrdeutig - vgl. 
place - die einen übersetzen es als Siedlung, die anderen als eine 
unscharf umrissene, beliebig große Region (Erde, Eurasien,vorderer 
Orient,Alpen,Berlin,Neunerbrücke)).


- Ein Aufruf zur behutsamen Pflege/care wäre hier imho besser 
gewesen.  Jeder, der das Wiki verbessern möchte, sollte wissen, dass es 
sich nicht um eine reine, stumpfe Übersetzungsarbeit nach Schema Ü 
handelt.  Je nach Popularität der entsprechenden Seite, sind Interessen 
anderer abzuwägen und evtl. mehrtägige Recherchen auf talk-de oder in 
der history fällig, um sich auf eine etwaige flood of complaints 
vorzubereiten..



lg
Christian



Am 17.03.2012 20:48, schrieb ssho...@gmx.de:

Hallo,

die OSM-Wiki[1] ist die wichtigste Ressource für Mapper und sollte daher
in allen Teilen gut lesbar und einfach zu verstehen sein. Das dies im
Moment nicht der Fall ist, dürfte jedem klar sein. Mit dem deutschen
WikiProjekt Cleanup haben wir eine Möglichkeit geschaffen,
Übersetzungsbemühungen zentral zu koordinieren.

Damit dies effektiv funktioniert, benötigen wir Eure Hilfe: Auf der
Projektseite[2] findet Ihr Hinweise, wie ihr zu übersetzende Artikel
markieren könnt.

Unser Vorschlag: Da am kommenden Dienstag aufgrund von Wartungsarbeiten
keine Edits an der OSM-Datenbank vorgenommen werden können, schaut doch
mal auf der Projektseite[2] vorbei und sucht Euch einen Artikel zum
Übersetzen. Selbst wenn es nur ein Absatz oder ein kleiner Artikel ist:
Ihr helft damit der Gemeinschaft und somit auch OpenStreetMap!

Grüße
Rob

[1]: http://wiki.openstreetmap.org/wiki/DE:Hauptseite
[2]: http://wiki.openstreetmap.org/wiki/DE:WikiProject_Cleanup

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




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

Re: [Talk-de] Start des deutschen WikiProjekts Cleanup

[Christian Müller]

Hi,


Am 18.03.2012 15:58, schrieb ssho...@gmx.de:

Hallo Christian,

deine Meinung zu diesen Thema [...]


Diese Meinung ist das Produkt gesammelter Erfahrung, ich gebe sie preis, 
damit andere im Vorfeld abschätzen können, worauf sie sich einlassen.  
Deine Einstufung als Musterbeispiel bestätigt die Notwendigkeit ihrer 
Veröffentlichung - leider.




Bevor das deutsche WikiProjekt Cleanup gestartet wurde, wurden mehrmals
diverse OSM-Wiki-Admins angeschrieben, mit der Bitte um Stellungnahme
und Unterstützung. Wir erhielten – bis zum heutigen Tag – keine Antwort.


Es ist schade, dass zu hören.  Vermutlich erwachen diejenigen erst nach 
wiki edit.  Du schreibst nichts über den Zeitraum und den Umfang der 
Kontaktaufnahmen und auch nicht darüber, wer kontaktiert wurde.  Wie 
bist Du vorgegangen, um rel. OSM-Wiki-Admins zu ermitteln?




Weiterhin sollen in erster Linie die wichtigsten Seiten die zum Mappen
notwendig sind übersetzt werden.


Ich finde die Koordinierung über die Template-Methode grundsätzlich gut 
und auch die Idee, Seiten zu identifizieren, die noch gar nicht 
übersetzt wurden.  Dennoch, die Formulierung mancher Sätze, mit denen 
zur Überarbeitung motiviert wird, klingen, als ob große Teile der dt. 
OSM Wiki bisher gänzlich unbrauchbar wären - die wichtigsten Seiten, 
welche zum Mappen notwendig sind sind IMHO vorhanden.


Daher schrieb ich, wäre es besser gewesen zu einer behutsamen 
Veränderung und Pflege aufzurufen, mit Rücksicht darauf, dass bestimmte 
Übersetzungsfehler später zu Problemen in der gesamten DB führen können 
- weil z.B. dem Übersetzer place als Siedlung geläufiger war, als 
Ort und er sich der Bedeutung dieser Differenzierung im OSM-Kontext 
nicht gegenwärtig war, als er, hypothetisch gesprochen, alten Content 
überschrieben hat.


Das sind nur praktische Probleme, die ich da sehe - keine 
grundsätzlichen.  Es ist halt nicht von Vorteil, wenn jemand statt dem 
ersehnten Beifall für seine Mühen, einen umgehenden revert seiner edits 
kassiert..


Dass das Wiki von einigen als OSM-Bibel wahrgenommen wird, die dann 
nicht mehr in der Lage sind abweichende Methoden zu tolerieren, macht es 
nicht leichter, Formulierungen zu finden, die Mapper zur Kooperation er- 
statt entmutigen.



Gruß und viel Erfolg,
Christian



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

[Talk-de] Einzelspurmapping (war Re: Fahrspuren die 315.)

[Christian Müller]

Hi,


ein Gedanke, um erlaubte Spurwechsel zwischen einzeln gemappten Spuren
ohne Relationen abzubilden:


- recycle den kompletten access - Baum
- es kann sein, dass Spurwechsel nicht für alle oder nur einen Teil von
Fahrzeugen in eine bestimmte Nachbarspur möglich sind

- tagge Spurwechselmöglichkeit relativ zur aktuellen Spur

- Tagformat:   access-key:lane={left,right,both,stay,none}


Beispiel 1:

links und rechts der aktuellen Spur befinden sich Spuren in die
jedes bel. Fahrzeug wechseln darf

aktuelle Spur
access:lane=both

linke Spur
access:lane=right

rechte Spur
access:lane=left

die Weglänge vor der Kreuzung, auf der ein Wechseln nicht mehr
möglich ist
für alle Spuren
access:lane=stay


Beispiel 2:

es gibt nur eine Spur pro Richtung
access:lane=none   (dies ist der Default-Wert und braucht nicht
extra getaggt zu werden)


Beispiel 3:

4 Spuren - Links abbiegen, BUS-Spur, über die nicht gewechselt
werden darf, Geradeaus, Rechts abbiegen

ganz links
access:lane=stay
psv:lane=right

die Busspur
psv:lane=both

geradeaus
access:lane=right
psv:lane=left

ganz rechte Spur
access:lane=left


Zur Bedeutung der Werte:
left - es kann (aber muss nicht) in die linke Spur gewechselt werden
right - es kann (aber muss nicht) in die rechte Spur gewechselt werden
both - es kann in die linke oder rechte Spur gewechselt werden
stay - es sind noch andere Spuren da, aber die aktuelle Spur muss
gehalten werden
none - es gibt keine andere Spuren (in die gleiche Richtung) - dies
ist der Default-Wert


Vorteile:
- es kann auf das Anlegen von Relationen für Spurwechselinfo
verzichtet werden
- es kann auf die Erfassung einer highway area verzichtet werden
- es werden keine Relationen angelegt
- die Erfassung ist auch noch für newbies einfach

- die Spurwechselinfo hängt am osm-way, also der aktuellen Spur
- die Info kann pro Spur erfasst werden, folgt also dem Ansatz,
Spuren separat
  erfassen und prüfen zu können

- falls praktikabel, kann für entgegenkommende Spuren, die für
Überholvorgänge benutzt werden dürfen, _opposite benutzt werden, um den
Wertebereich zu erweitern  (Analog zu cycleway-Werten)

Nachteile:
- es gibt keinen expliziten Spurzusammenhang, wie bei Relationen
- eine routing engine kann durch die Angabe des Mappers erkennen
- dass Spuren existieren
- mit welchen Fahrzeugen, in diese Spuren geroutet werden dürfen
- .. aber er muss diesen Nachbarweg an der Stelle selbst aus den
Daten fischen, um ihn im Routing-Graph berücksichtigen zu können


Gruß
Christian


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