[OSM Dortmund] Arbeitsmatrix osm-intern / Validierung

[o.hasemann at gmx.de]

Hallo allerseits,

der Vorschlag war sicherlich sehr knapp und auch noch nicht
ganz ausgereift formuliert und die aufgeführten Kontra sind sicherlich
Schwachstellen.
 
Am Montag, 3. Mai 2010 10:27 schrieb Dietmar:
> Hallo Olafe (oder Olafs?),
>
> die osm-interne Idee finde ich gut.
>
> Die Luftbilder und OSM-Daten sind besser als in der bestehenden Matrix
> vergleichbar und Daten im selben Programm zu pflegen.
>
> Die Erstellung der Matrixelemente über bestehende Grenzen wie z.B. Straßen
> fand ich zuerst erst super, aber:
>
> die Stadtfläche hat 280 km2, die bestehende Matrix hat schon 300 Elemente
> und das ist den lokalen Mappern noch zu wenig.

Zu wenig nur in sehr dicht bebauten Gebieten wie der Innenstadt. Mehr als 10
Wohnblöcke sind da schon sehr unübersichtlich. In anderen Bereichen könnten
die Areas durchaus größer ausfallen. Auf eine größere Anzahl von Relationen
(Multipolygonen) wird das aber auf jeden Fall hinauslaufen.

> Wenn ich nur von 300 Relationen ausgehe, die händisch über begrenzende Wege
> (ggfs. noch vorab jeweils zu splitten), dann ist das ein hoher Aufwand.

Auf gar keinen Fall währe es praktikabel 'nur' bereits vorhanden Elemente wie 
Wege oder Landuse Grenzen nutzen zu wollen. Das Ziel, diese Elemente 'auch'
zulassen zu wollen ist: 

	-> Möglichst wenige neue / zusätzliche Wege im OSM-Datenbestand
	-> Die Form der Gebiete soll den Bedürfnissen entsprechend angepasst
            werden können (z.B. Klinilkviertel, Gleisdreieck oder aktuell
	    Zielgebiet Mappingparty)

	-> Wenn ein Element (z.B. Straße ) ein Gebiet abgrenzt, kann ich es
	    schnell zum Multipolygon hinzufügen

Elemente nur für diesen Zweck zu splitten, finde ich nicht wirklich sinnvoll, 
das ganze soll ja 'spurlos' auch wieder beseitigt werden können.

Beim Erstellen der Gebiete sollte extrem pragmatisch vorgegangen werden,
also etwa: ? ist das Ding (die Straße) genau passend, dann aufnehmen, wenn
nicht: ctrl klick klick... neuer Weg ohne Tags und ab in das multipolygon.

Das schließt den Vorschlag initial eine Flächendeckende Vorlage zu erzeugen
ein, da auch sehr pragmatisch.
  
> Ich habe mal die beiden Möglichkeiten sowie eine eigene dritte Idee hier
> versucht, zu vergleichen, bitte die Vor-/Nachteile vervollständigen:
>
> bestehende Arbeitsmatrix:
> + existiert
> - es fehlen unsere Elemente Gebäude und Hausnummern
> + fehlende Element ggfs. über Nutzung vorhandene andere Elementnamen
> nutzbar - zu grob (nur eine Meinung oder meinen das mehrere lokale Mapper)
> - Vergleich Luftbild/OSM-Daten über Regler nicht so einfach prüfbar, oft
> hin und herzuschieben (in JOSM Luftbilder und dann suchen durchführen
> bringt bessere Prüfungsmöglichkeiten)
> - Auswertung nur optisch?
>
> Idee Relation mit bestehenden Grenzen (z.B. Straßen):
> + am besten für Arbeitsgebiete der lokalen Mapper anpassbar
> - hoher Aufwand, händisch zu erstellen, ggfs. Wege zu splitten
Splitten finde ich nicht gut, außer es macht auch aus anderen Gründen Sinn

> - erst auswertbar, wenn für Gesamtgebiet die Relationen vorliegen
da bin ich mir nicht ganz so sicher, nach klassischer open world assumption
bedeutet ein nicht abgedeckter Bereich innerhalb der Stadtgrenzen:
eine Validierungsaussage wurde bisher nicht getroffen (also N.N.).
Ob das auch 'einfach' auswertbar ist, ist noch zu diskutieren.

> Idee Matrix osm-intern im Editor
> + Matrix-Größe definierbar
> + Aufwand relativ gering, händisch oder mit relativ einfachem Programm
> + gute Auswertemöglichkeit, da Gesamtfläche aller Matrixelemente
> automatisch 100% des Gesamtgebiets
> - nervt vermutlich optisch in den Editoren
solange kein Tag area=yes oder vergleichbares verwendet wird, sind nur die
grenzen sichtbar, das fände ich akzeptabel. Noch mehr graue Überlagerungen
fände ich hingegen nicht so schön.

> - kann beim zeichnen nerven, wenn Cursorpostion in Nähe Matrix
in josm: ctrl maus-klick
da die Form der Matrix zwar flächendeckend, aber flexibel sein soll,
würden Editierunfälle nicht einmal stören.

Noch ein Nachtrag zum Arbeitsablauf:

Wenn wir alle validation-areas in eine validation-collection packen,
kann man die ganze 'matrix' mit einem Full-request in den Editor holen
oder aktualisieren.
Wer neue Aufgabenfelder sucht, kann sich dann
(in josm) mit: find:  purpose=validation -"ok:buildings"=100
ein neues Aufgabengebiet suchen

Wenn jemand in einem bestimmten Gebiet arbeiten möchte, so
grenzt er dieses zunächst grob ab (falls es nicht schon passt)
und könnte mit dem tag:
	processing=<username>
anzeigen, dass er sich der Gegend annimmt. Per Konvention verliert
ein solcher Lock nach ? einem ? zwei ? Tagen seine Gültigkeit,
was von jedem in der History nachgesehen werden kann.

Ob alles noch in einer speziellen Map zusammengefasst wird, oder
ob die Standart Abfragen wie:

http://www.openstreetmap.org/browse/relation/<nummer der Area/ ganze matrix>

ausreichen, sei erstmal offen gelassen.

Ich hoffe, dass hat jetzt nicht zur allgemeinen Verwirrung beigetragen,
Grüße
Olaf Hasemann
 
>
> Grüße Dietmar
>
> > -----Ursprüngliche Nachricht-----
> > Von: dortmund-bounces at lists.openstreetmap.de
> > [mailto:dortmund-bounces at lists.openstreetmap.de]Im Auftrag von Olaf
> > Kotzte
> > Gesendet am: Sonntag, 2. Mai 2010 21:42
> > An: OSM in Dortmund
> > Betreff: Re: [OSM Dortmund] Einladung Mapper Treffen Sonntag 2.Mai
> > /Validierung / Arbeitsmatrix
> >
> > Hallo,
> >
> > wir waren heute nur ein sehr kleiner Kreis und haben effektiv nur
> > das Thema Mapping Party beraten.
> > Diskussionen zu diesem Thema hier sollten wir erstmals hier auf
> > der Mailingliste austragen.  Und damit fange ich jetzt mal an.
> > Wie soll das von dir vorgeschlagene Verfahren in der Praxis
> > funktionieren? Ich stehe da im Moment etwas auf der Leitung.
> >
> > Viele Grüße
> >
> > Olaf
> >
> > Am 02.05.2010 um 17:44 schrieb Olaf Hasemann:
> > > Hallo allerseits,
> > >
> > > vielleicht könnt ihr ja noch folgende Idee zum Thema
> >
> > Validierung/Arbeitsmatrix
> >
> > > diskutieren:
> > >
> > > Was spricht eigentlich dagegen, die Matrix nicht extern, sondern intern
> > > umzusetzen, also direkt in den OSM Daten?
> > >
> > > Der Vorteil aus meiner Sicht:
> > >
> > > 	-beim editieren kann die Validierung direkt
> > > 	durchgeführt werden, kein Abgleich mit externen Tools ist notwendig.
> > >
> > > 	-Die OSM Datenstruktur ist viel flexibler als jede Matrix
> >
> > es jemals sein kann
> >
> > > Eine erste Idee hierzu währe in Anlehnung an die Search And
> >
> > Resqueue Areas:
> > > 	> Aufteilen des Gebietes in multipolygone (areas)
> > > 	>dabei durchaus die 'natürlichen' Grenzen nutzen
> > > 	>die Granularität den Mappern frei lassen
> > > 	>keine Tags benutzen, die von Renderern interpretiert werden
> > >
> > > Als Beispiel habe ich mal eine (nicht hochgeladene) Relation
> >
> > zusammengestellt:
> > >  <relation id='-78' action='modify' timestamp='2010-05-02T14:07:21Z'
> > > visible='true'>
> > >    <member type='way' ref='-64' role='outer' />
> > >    <member type='way' ref='-42' role='outer' />
> > >    <member type='way' ref='-46' role='outer' />
> > >    <member type='way' ref='-68' role='outer' />
> > >    <member type='way' ref='-66' role='outer' />
> > >    <member type='way' ref='-58' role='outer' />
> > >    <member type='way' ref='-52' role='outer' />
> > >    <member type='way' ref='-54' role='outer' />
> > >    <member type='way' ref='-50' role='outer' />
> > >    <tag k='ok:areas' v='50' />
> > >    <tag k='ok:buildings' v='100' />
> > >    <tag k='ok:cycling' v='0' />
> > >    <tag k='ok:housenumbers' v='1' />
> > >    <tag k='ok:public_transport' v='1' />
> > >    <tag k='ok:streets' v='100' />
> > >    <tag k='purpose' v='validation' />
> > >    <tag k='todo:areas' v='partitionierung aufräumen' />
> > >    <tag k='type' v='multipolygon' />
> > >  </relation>
> > >
> > > Das Tagging Schema soll nur ein Beispiel sein, die Idee ist,
> >
> > für die einzelnen
> >
> > > Aspekte eine numerische Bewertung zu haben, die maschinell
> >
> > ausgewertet werden
> >
> > > kann (ok:xxx), und einen umgangssprachlichen Hinweis, was noch
> >
> > zu erledigen
> >
> > > ist (todo:xxx).
> > >
> > > Vielleicht könnt ihr es ja noch beim Treffen diskutieren, ich
> >
> > bin auf jeden
> >
> > > Fall auf eure Meinung gespannt, auch wenn diese lautet: Das geht ja
> > > garnicht  ;-)
> > >
> > > Grüße
> > > Olaf Hasemann
>
> _______________________________________________
> Dortmund mailing list
> Dortmund at lists.openstreetmap.de
> http://lists.openstreetmap.de/mailman/listinfo/dortmund