Hallo Rhinhold.

Auf der einen Seite gebe ich dir recht: Ja, OSM könnte an vielen Stellen (end-)benutzerfreundlicher werden, gerade auf Exportseite.
Auf der anderen Seite ist aber genau das das Problem:

Auch als Informatiker hilft mir ein benutzerfreundlicher Editor, denn das Bearbeiten der Daten ist immer weitgehend gleich oder zumindest vergleichbar.

Die Nutzung der Daten ist dagegen aber leider so extrem facettenreich, dass es einfach nicht genug Interessenten gibt, um eine benutzerfreundliche Lösung in einer Facette so weit voranzubringen.

Es gibt Nischen, in denen das ja schon passiert:
- Die Geofabrik-Extrakte bedienen alle, die einfach nur Ausschnitte für bestimmte Länder brauchen - diverse Garmin-Karten bedienen zwar mit vorgegebener Auswahl, aber doch die Gruppe der Garmin-Nutzer - Der Export von Bildern als SVG oder Rastergrafik direkt auf der Webseite bedient Grafiker, Layouter oder sonstwen, der einfach mal eben ein Kartenbild braucht. - Nominatim etc. bedienen alle, die nur mal nachschlagen wollen, wo Hintertupfingen liegt.

und so weiter.

Die Zielgruppe für "alle Siedlungsgebiete" ist nunmal (aus deiner Sicht leider) ziemlich klein. Wenn da dann niemand dabei ist, der es umsetzen will und kann - oder sich jemanden sucht, und davon überzeugt, dass das sinnvoll investierte Zeit 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).

Wenn Du nun argumentierst, du könntest da nicht helfen, dann stelle ich, ohne mich damit als Programmierer direkt anbieten zu können, doch einfach mal die Frage zurück, die nämlich keine Programmierkenntnisse voraussetzt: Wie sollte denn die Exportmöglichkeit (als Programm, Web-Schnittstelle oder was auch immer) aussehen, die du dir vorstellst? Denk dran, dass eben nicht genau dein Problem das wäre, was diese Komponente leisten müsste, sondern "solche Anfragen" aller Art, die auch von beliebigen anderen Usern aus anderen Anwendungsbereichen kommen könnten.

Vielleicht hast du ja eine Idee, die sich tatsächlich umsetzen ließe - und die jemanden findet, der das gerne tun würde.


Gruß
Peter

Am 11.09.2011 13:04, schrieb Rhinhold:
Hallo Frederik und Christian!
Danke für die Antworten!

@Frederik:

Das ist leider nicht ganz leicht. Zwar gibt es Flaechen, die in OSM mit 
"landuse=residential" als Wohnflaechen eingetragen sind, aber die sind 
mitnichten komplett. Schau Dir z.B. mal diese Karte von Muenchen an:
http://www.openstreetmap.org/?lat=48.15772&lon=11.53345&zoom=16&layers=M
Nur im Nordosten des Bildes, im Stadtteil Ebenau, ist tatsaechlich eine 
Siedlungsflaeche eingetragen (etwas dunkleres Grau). Der ganze Rest (helleres 
Grau) hat keine Siedlungsflaeche.
Das liegt daran, dass die Mapper wenig Motivation haben, eine Siedlungsflaeche in einer 
schon mit Strassen und Haeusern dicht befplasterten Gegend einzuzeichnen ("man sieht 
ja, dass da Leute wohnen").
Hm, das scheint in München tatsächlich nicht ganz unproblematisch zu sein. Jedoch trifft 
dies regional mit unterschiedlicher Intensität auf - so mein Eindruck. Beim Kontrollieren 
meiner ländlichen (!) Untersuchungsregionen (links und rechts des Rheins bei 
Karlsruhe/Mannheim) habe ich eine schöne Konsistenz den Einsatz des 
"residential"-Tags betreffend vorgefunden. Aber natürlich können auch dort 
Fehlerflecken auftauchen.

Nichtsdestotrotz wäre es einen Versuch wert.
Der Kartenausschnitt, den ich damit zeigen möchte, ist zudem so groß, dass es nicht auf 
"vergessene" Gewerbegebiete oder Neubaugebiete ankommt, sondern vielmehr um die 
Lage der Siedlung innerhalb ihrer Gemeindegrenze. Also, solange keine eklatanten 
Missstände auftreten, sind die kleinen Fehler zu vernachlässigen.


Ein Landuse-Shapefile kannst Du Dir u.a. auf den folgenden Wegen selbst 
erzeugen:
1. osm2pgsql - geht auch fuer grosse Dateien, erfordert PostGIS (danach 
pgsql2shp), auf einem aktuellen Ubuntu/Debian-System kann man das aber alles 
als fertige Pakete installieren.
2. osm2shp aus dem OSM-Subversion-Repository 
(svn.openstreetmap.org/applications7utils/(export/osm2shp) - musst Du selbst 
compilieren und im C-Source angeben, was Du exportieren willst; sehr einfaches 
Programm, kann keine Multipolygone
3. osmjs, ein Teil von Osmium (wiki.openstreetmap.org/wiki/Osmium), das ist das 
beste, was es in Sachen Shape-Erzeugung derzeit gibt, kann Multipolyone und 
wird ueber ein Javascript-Schnipsel gesteuert; auch da musst Du allerdings 
selber compilieren und dann in Javascript definieren, was Du genau exportieren 
willst.
Ach, ich sehe schon, ein echter "Traum" für jeden Nicht-Informatiker. :)
Nicht beleidigt seien, aber zum großen Teil verstehe ich hier nur Bahnhof. Was 
mich wiederum zum nächsten Thema überleitet...


[Alles zusammen hat mich
mehrere Stunden meiner Arbeitszeit gekostet - was irgendwie nicht
Sinn der Sache sein sollte/kann]
Du kannst ja ueberlegen, was Du dazu beitragen kannst, dass es besser wird ;)
Also, als jemand, der seine Kenntnisse tendenziell außerhalb von 
Programmiersprachen und Netzwerklogiken verorten würde (s.o.), sehe ich da 
wenig Möglichkeiten, konkret Abhilfe zu schaffen. :)

Insgesamt ist mir ein wenig schleierhaft, wie es unzählige Möglichkeiten des Datenexports geben, aber (fast) 
keine davon benutzer- und einsteigefreundlich sein kann. Immerhin hat es die OSM-Gemeinde ja schon geschafft, 
die Dateneingabe soweit zu vereinfachen, dass man mittlerweile wirklich behaupten kann "jeder kann 
mitmachen". Davon sind wir - meiner Meinung nach - beim Datenexport aber noch meilenweit entfernt (was 
Dienstleistern, wie der Geofabrik nicht unbedingt sauer aufstoßen sollte :) ). Aber gerade Menschen, die 
diese Daten wirklich nutzen möchten, aber kein Verständnis von den notwendigen Prozeduren haben (wie meine 
Wenigkeit), sehen sich hier schnell vor dem Scheitern. Somit bleibt für mich als "außenstehenden" 
Mapper offen, inwiefern OSM denn wirklich "frei-zugängliche Daten" haben soll.



@Christian:

.. habe ich mir angeschaut, bin aber dann schnell an fehlender Einsteigerhilfe 
und Fehler bei der Ausführung gescheitert.
[Alles zusammen hat mich mehrere Stunden meiner Arbeitszeit gekostet - was 
irgendwie nicht Sinn der Sache sein sollte/kann]
Die Datenerfassung in OSM kostet ebenso zahlreiche Arbeitsstunden, irgendwie 
beschwert sich da niemand über den Sinn der Sache ;-)
Eeeben. Gerade *weil* die Datenerfassung doch so (zeit-, nicht technisch) 
aufwendig ist, muss man das gleiche Spiel doch nicht noch einmal auf der 
anderen Seite der Datenebene durchkauen. :)


Grüße,
Rhinhold
_______________________________________________
Talk-de mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-de



_______________________________________________
Talk-de mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-de

Antwort per Email an