Hallo alle miteinander, zu allererst finde ich es schön, dass hier offensichtlich die Bereitschaft zur offenen Diskussion vorhanden ist. ;)
> [...] dann ist das halt ein Problem, aber kein Grund, sich darüber zu > beschweren (kein Vorwurf, die Beschwerde war zumindest nicht deutlich, aber > man könnte sie in deine Mail reininterpretieren). Es sollte auch keine Beschwerde im ursprünglichen Sinne sein, sondern vielmehr eine Art, zu zeigen, wieviel Frust sich in einem anstauen kann, wenn es nicht gelingt, trotz Wille und Zeit Ergebnisse produzieren und am Ende jegliche Mühe als gescheitert ansehen muss. Dabei bin ich ein sehr genügsamer Mensch. :) Nun sehe ich aber vollkommen ein, wenn Peter einwirft, dass die Vereinbarkeit von OSM-Rohdaten und den spezifischen Nutzungswünschen nicht ohne weiteres zusammenzubringen ist. Da ich selbst ab und an kartiere, habe ich das unendliche Diskussionspotenzial um die Auslegung von Tags auch schon miterlebt. Daher wird es so oder so keine Perfektion geben - so wie eben das ganze OSM-Gebilde niemals perfekt sein kann und wird. Was man aber tun kann, ist einen größtmöglichen Spielraum zu schaffen, der - ständig weiterentwickelt - einen immer größer werdenden Nutzerpool (mit entsprechenden Bedürfnissen) erreicht. Aber zurück zur konkreten Ebene: Ich finde den Ansatz von ant sehr richtig, der da sagt: > Mir schwebt in etwa Folgendes vor: Ein Web-Interface oder > Programm mit GUI, in dem ich ein Rechteck oder Polygon über eine Karte > ziehe und sage, welche Daten (Tags) ich möchte. Das Programm holt für > mich die Daten und filtert sie, wandelt sie ggf. um, und dann kann ich > damit tun, was ich möchte (z.B. in QGIS laden oder in eine DB importieren). Nichts anderes haben doch auch schon informationfreeway.org (wenn es denn mal gänge) und das Stuttgarter Pendant versucht und in Teilen erreicht. Sowohl beim einen als auch beim anderen definiere ich eine BBox und die Information, die ich haben will (mit der Voraussetzung, dass man sich mit den Tags etwas auskennt). Danach lasse ich mir das als gpx-, kml-, shp oder sonstige Datei ausgeben (je nachdem, wie die technische Umsetzbarkeit ist). Somit sind meiner Ansicht nach die Techniken doch schon vorhanden. Was lediglich fehlt, ist einfache Handhabung. Und hier kranken die meisten Ansätze meiner Meinung nach. Dabei geht es, wie ant auch schon angerissen hat, auch einfacher: > wenn ich in Potlatch ein Restaurant eintragen will, klicke ich auf das > Symbol mit Messer und Gabel und fertig. Das kommt der sprachlich > formulierten Aufgabe schon sehr nahe. Wer dennoch spezielle Tags > eintragen möchte, klickt auf "Advanced" und tippt Schlüssel und Wert > ein. Dieses Konzept lässt sich auf beliebige Anwendungen übertragen. Übersetzt in die Export-Perspektive bedeutet dies, man müsste ein kleines und erweiterbares Sammelsurium an Vorlagen (oder besser: Tag-Pakete) bereitstellen. Diese könnten dann z.B. lauten: "Ich möchte alle Gewässer!" - darin enthalten sind dann sowohl Flüsse, Bäche, Seen, Polter, etc. "Ich möchte alle Flüsse!" - und er bekommt nur die Flüsse, nicht aber die Bäche und Seen, etc. Letztlich ist also doch nur eine Kombinatorik von Tag-Elementen erforderlich (außer vllt. bei Relations, oder?). Und alles, was die Vorlagen nicht erfassen (oder falsch erfassen), kann man mit einem "Advanced"-Button direkt selektieren oder eben de-selektieren. Also? Peter dazu: > Alles in Allem schreit das für mich nach 'ner Aufgabe für osmembrane: Die > Karte zur bbox-Auswahl sollte nicht so kompliziert sein, ein Polygon zu > zeichnen auch nicht, bleibt die Vereinfachung der Tag-Auswahl. Dito. OSMembrane macht bereits vieles richtig, scheitert aber aus meiner Nicht-Informatiker-Sicht (noch) völlig an der Usability. Der Mehrwert dieser Applikation ist somit gegenüber der manuellen Texteingabe eher gering. Aber das Potenzial ist riesig, da die Basis ja schon steht. Soweit mein Senf. ;) Grüße, Rhinhold _______________________________________________ Talk-de mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-de
