Wenn du dich klar ausdrücken kannst, gerne. Erst schreibst du dass man nur eine Darstellung anbietet, dann vielleicht doch 2. Auf der Renderer-Seite ist das eben eine enorme Zusatzlast für die Rasterbilddaten. Es sei denn man macht Vektoroverlays, wo die Rechen- und Speicherlast auf Client-Seite entsteht. Das obige Beispiel mit http://parking.openstreetmap.de hat mir schon gefallen. Ich konnte nur der Javascript-Karte nicht entnehmen, ob die transparent drübergemalten Linien als Vektoroverlay per Javascript im Browser entstehen (noch eine JS-Library beteiligt), oder ob der Server das alles noch als Rasterdaten mit Alphakanal liefern muss (das wären ja genauso viele Pixel wie die Grundkarte selbst). In beiden Fällen wäre das aber prinzipiell unabhängig von OSM (*), könnte also aus beliebiger Internet-Resource hinzugemischt werden.
(*) d.h. man hätte kein Problem mit der referentiellen Integrität verschiedener Datenbanken,
wenn man die Wahlkreise einfach nur aus den von der Amtsseite gelieferten Shape-Dateien generiert.
Und die wertvolle Zeit der Mapper bliebe verschont davon.
Vor allem sehe ich eine solche Architektur als Prototyp für viele anderen denkbaren Überlagerungen
für die Defaultkarte.
(zwischen dem und einem funktionierenden Upload-Service, der nicht nur Striche anzeigt, sondern auch Beschriftungen, anklickbare Icons mit externen Bildchen, Flächen… liegen nur noch ein paar Wochenenden Arbeit)
Gibt es für Radfahrer hier z.B: http://www.komoot.de/ Zum Selberbauen finden sich sicher auch ein paar Open Source-Router.
Das kann man alles nachbauen. Drei bis vier Leute fürs Programmieren und die Webseite , ein oder zwei für die Wartung der Server, ein oder zwei für die Betreuung der Benutzer und natürlich jemand, der die Kohle ranschafft sollten reichen.
Und wir brauchen jemand, der das plant. Da kommst Du ins Spiel. Ich würde mit der Beantwortung von Walters Fragenkatalog anfangen und dann auf die Suche nach Server, Geld und Mitstreitern gehen.
Ja genau. Das ist doch Ok, oder? So macht die Wahlkreisekarte auch Sinn. Mit dem OSM-Rendering konnte man die Grenzen erst gar nicht erkennen, nur das die Beschriftungen wild in der Gegend auftauchten. Solche APIs sollte man öfter nutzen. Da könnte man sich viele Anwendungsfälle überlegen.
Ich hatte auch für Firmen mal Geodatenvisualisierung programmiert (nur nebenher). Sehr praktisch war das mit Google Earth. Da musste gar kein Webserver aufgesetzt werden, sondern man konnte die KML/KMZ-Datei einfach herumschicken und jeder konnte das Overlay für sich darstellen. Das erspart viel Organisationsaufwand, gerade für Ad-Hoc-Projekte. Auch die Produktion der KML-Dateien aus Anwendungsprogrammen heraus ist supereinfach.
Das fehlt jetzt eigentlich nur noch für OpenStreetMap. Nicht jeder will ja gleich für seine Anwendung einen Webserver installieren. Bei Google Maps habe ich schon viele Overlays gesehen, aber noch keine wo man KMLs von der eigenen Festplatte überlagern kann. Das geht bisher nur mit Google Earth.
Solltet ihr mal testen. Bisher kann man Fotos und Wikepedia-Artikel einblenden.
Leider geht es noch nicht mit eigenen Daten (KML Linien/Flächen/Images oder GPX-Tracks).
Ich schaue mir einfach gerne mal meine GPS-Tracks aus dem Smartphone an, wenn ich
weite Radtouren durch unbekannte Landschaften gefahren bin.
Andersherum kann man in Google Earth auch gut zur Planung einen Polygonzug abstecken,
der dann in OsmAnd als Route erscheint, für unterwegs.
Wow, sehr schön. Der routet tatsächlich um den Berg herum.
OsmAnd wollte mich direkt über den Gipfel routen.
Wenn ich Lust habe fahre ich gerne rauf, aber manchmal will ich einfach nur ohne Anstrengung schnell nach Hause.
Nur schade, dass jetzt der Kälteeinbruch bevorsteht.
Eine wichtige Motivation zum Radfahren ist für mich die Einkehr in einen Biergarten.
Im Winter macht mir das alles keinen Spaß mehr.
Außerdem mag ich die Wälder nur grün, oder herbstlich mit Sonnenschein
Eigentlich halte ich mich aber selbst für die besten Fahrrad-Router. Ich vermeide möglichst alle Straßen mit Autoverkehr,
nehme auch gerne Waldwege, kleine Bachläufe … Ich bin noch skeptisch mit der Maschinenintelligenz, ob ein
Computer die für mich schönste Route errechnen könnte.
Meine Routenplanung im PC mache ich normalerweise in Google Earth, indem ich ein Polygon zeichne,
KML zu GPX-Konvertierung und dann in OsmAnd einspielen. Der kann anhand dieses GPX sogar akustische
Abbiege-Anweisungen geben. Naja, ich schau aber dann doch lieber mal auf die Karte, zur Sicherheit.
Oder manchmal lege ich auch nur ein paar Waypoints an, die ich besuchen will.
Meist fahr ich sogar ohne Plan los, ohne überhaupt zu wissen wohin es gehen soll.
Einfach mal Kalorien und Stress abbauen, nach einem langen Arbeitstag.
Automatisches Routing mache ich z.B. wenn ich irgendwo mitten im Waldgebiet stecke, es stockduster wird
und ich schnell einfach nach Hause will. Da habe ich dann auch Probleme mit der Sichtnavigation.
Gut, dachte ich, OsmAnd bringt dich schon nach Hause. Aber dann habe ich gemerkt, dass der die Berge
wieder hochwill, die ich gerade heruntergekommen bin. Was für ein Schwachsinn. Die Tal-Route ist
zwar nur ein paar km länger aber deutlich weniger anstrengend und viel flotter.
Was mir an OsmAnd gefällt, dass das Routing komplett von der Speicherkarte funktioniert, ohne
Netzverbindung. Da wo ich fahre gibt es oft sowieso kein Netz. Außerdem habe ich nur eine
150 MB Mini-Flatrate. Tja, dachte ich, wäre nett wenn OsmAnd die Höhe berücksichtigen könnte.
Aber wenn man mal genau nachdenkt ist das schon problematisch. Es wäre natürlich schön wenn OpenStreetMap
selbst Höhendaten bereitstellen würde. Aber das ist ziemlich kompliziert. Die GPS-Geräte können die Höhe nur sehr
ungenau messen, gerade im Gebirge mit Multipath-Ausbreitung der GPS-Signale.
Das Editieren erfolgt ohnehin auf einer 2D-Karte. Also würden beim Zeichnen ohnehin keine 3D-Daten entstehen.
OsmAnd hat die Höhen als separates Overlay. Das sieht gut aus, mit Höhenlinien wie auf einer topografischen Karte.
Aber in dieser grafischen Form sind sie kaum im Routing-Algorithmus automatisch zu verarbeiten.
Man müsste entweder die ganze Kartefläche als Raster von Höhenwerten abdecken,
oder Höhenwerte den Vektordaten gleich bei der Kartenproduktion einkodieren.
Beides hätte Vor- und Nachteile.
Im Idealfall würde man die Daten der Landesvermessungsämter nehmen, weil die wirklich genau vermessen haben.
Sind die als OpenData schon freigegeben? Ich denke langfristig würde das schon in die Richtung gehen.
Bis dahin hat man immerhin die STRM-Daten der NASA.
Falls OSM-Objekte dreidimensionale Koordinaten bekommen, wäre es sicher am besten, diese nachträglich
aus einer Höhenkarte zu ergänzen. Denn an der Höhe gibt es normalerweise gar nichts zu editieren.
Z.b. ist die STRM-Höhenkarte flächendeckend. Es gibt also auch Höhendaten für Positionen auf denen noch
gar keine OSM-Objekte stehen.
“Mal eben so” ist das nicht zu machen. Das wird grundlegende Neudefinitionen der Datenformate benötigen.
Die aufbereiteten Vektorkarten für die Smartphone-Apps sind vermutlich nur auf 2D-Koordinaten ausgelegt.
Änderungen sind dann in erster Linie an der Smartphone-App und am Programm für die Datenaufbereitung zu machen.
Man müsste sich dann da irgendwo einbringen: http://code.google.com/p/osmand/
Die meisten anderen mir bekannten Offroad-tauglichen Android-Apps bieten leider nicht so schöne
Routing- und Vektorkartenmöglichkeiten. Ein Highlight wie gesagt die Wikipedia-Artikel, die es zum Reiseführer machen.
Sehr schön im Ausland, wo man auch ohne Roaming-Gebühren alles machen Kann.
Ein paar Gigabyte Wikipedia habe ich natürlich auch auf der SD-Karte, wo dann die Voll-Artikel zur Offline-Nutzung
drin sind dt/engl. Nur die Bilder zu den Artikeln passen nicht mehr …
p.s.: ist ja total off-topic. Da könnte man mal ein eigenes Disskusions-Thema aufmachen.
Aber mach dir keine Hoffnung: ich bin schon zu 150% mit anderen Projekten ausgelastet.
Ideal wäre so etwas für einen Studenten, der so etwa in einer Masterarbeit realisieren würde.
Die muss sowieso publiziert werden, d.h. ist immer eine gute Resource für OpenSource Software.
Jetzt hätte ich fast gedacht, wäre doch etwas für das “Google Summer of Code” Sponsorhip. https://developers.google.com/open-source/soc/
Da wird jedesmal OpenSource weiterentwickelt. Aber hmm, mal nachgedacht, ist ja eigentlich
die Konkurrenz von OpenStreetMap. Ob die das dann sponsorn würden?
Schade das die Fahrrad-Saison bald vorbei ist. Im Winter mache ich keine langen Touren mehr.
Hast du den mal ausprobiert? Nimmt er direkt die STRM-Höhendatei und die Vektorkarte von OsmAnd?
Etwas nachteilig ist, dass die Integration in OsmAnd fehlt, d.h. es fehlt ein automatisches
Neuberechnen. Bei mir ist das auf dem Rad sehr häufig, da ich mit dem Router nicht immer
einer Meinung über die beste und schönste Wegeführung bin.
Ich missachte also regelmäßig die Routing-Anweisung
Zuletzt hatte ich den im Wald nur zur groben Orientierung eingeschaltet, da auf dem
kleinen Display das Waldwegenetz nicht so übersichtlich zu erkennen war …
und um in der Dunkelheit doch wieder nach Hause zu finden …
Genau das ist das Problem. Tolle Ideen haben viele. Manche haben sogar schon Karten ohne Wahlkreise und Router mit Höhendaten und Programme, die Tracks anzeigen. Was uns fehlt, sind Leute, die sowas dauerhaft anbieten, weiterentwickeln und supporten, idealerweise als Team, falls einer davon mal Freizeit haben will.
Bei Projekten ausserhalb von openstreetmap.org kann es uns egal sein, wenn die gar nicht erst entstehen oder nach ein paar Monaten floppen (egal ob technisch, organisatorisch, finanziell). Innerhalb von OSM wäre es uns nicht egal, weshalb man eben etwas langsamer vorgeht. Im Moment können wir froh sein, wenn ein paar Mapnik-Kundige das “alle Striche werden belabelt”-Problem lösen.
Das ist ja auch der Witz an OSM: Wir müssen nicht alles zusammen anbieten, jeder darf unser Zeug nehmen und selber loslegen.
Studentische Arbeiten sind selten nachhaltig. Oft sind die Leute weg, sobald sie den Schein dafür haben. Andere wollen zwar daran weiterarbeiten, stellen aber beim allgemeinen Wechsel der Lebensumstände nach dem Studium fest, dass ihre Prioritäten und ihre Zeiteinteilung plötzlich ganz anders aussehen.
Deswegen “Masterarbeit”. Die sind eher tiefgründiger als andere studentische Arbeiten. Gut, das Diplom damals war besser - da haben Leute im Schnitt 1 Jahr an ihrem Meisterwerk geschraubt. Eine Doktorarbeit ginge u.U. auch, aber da müsste man schon starke wissenschaftliche Aspekte an so einem Thema finden und ausarbeiten. Programmiert wird sehr viel bei solchen Arbeiten. Von grausamem Spaghetticode bis zur professionellen Anwendung hat man schon alles gesehen.
Für die vielen Studenten sucht man immer neue Themen, interessante Sachen die man mal ausprobieren oder untersuchen sollte. Manchmal entstehen dabei vollkommen theoretische Arbeiten, manchmal aber auch praktisch nützliche Untersuchungen inklusive Software. Ist nicht OSM selbst teilweise in studentischen Projekten entwickelt worden? Ich weiss, dass viele der freien GIS-Programme einen Uni-Bezug haben. Für die entsprechenden Lehrstühle ist das natürlich auch ein positiver Aspekt der Außendarstellung. Außerdem ist es Steuergeld - das kann ruhig in OpenSource oder OpenData-Projekte investiert werden. Natürlich suchen sich Akademiker immer einen wissenschaftlichen Bezug. Das Problem “geb mir die attraktivste Fahrradroute von A nach B”, oder verändere B entsprechend, dass die Tour noch schöner wird … geht doch schon fast in Richtung künstlicher Intelligenz. Mit Echtzeitbezug “ganz schön matschig hier …”.
Sicherlich ist die Kontinuität ein Problem. Wenn der Student geht, will er einen gutbezahlten Job. Bei ESRI würde er dann sicher keine OpenSource mehr produzieren. Aber das ist ja gerade das schöne an OpenSource. Der Code liegt offen und der nächste Student kann weitermachen. Egal wo auf der Welt.
Es gibt immer OpenSource-Projekte, die mangels Entwickler oder mangels Aufmerksamkeit einschlafen. Ebenso gibt es aber auch viele Erfolgsgeschichten von evolutionärer Entwicklung. QGIS wird mittlerweile auch gerne im akademischen Umfeld für professionelle Karten eingesetzt. ArcGIS kann sich nicht jeder leisten.
Man muss auch nicht nur Google als Beispiel nehmen, Geodateninfrastrukturen sind seit ~10 Jahren der letzte Schrei in der GIS-Welt. Grade INSPIRE wird da viel schaffen (standardisiert erfasste Geodaten, einheitliche Vokabulare für viele Themen über ganz Europa!).
Auch gibts ja die entsprechenden OGC-Webservice-Standards, die freie, standardisierte Services zum Abfragen von Kartenbildern und Vektorobjekten bieten. Auch OSM wird ja als WMS (Web Map Service) angeboten.
Hier ist aber ein Unterschied zwischen “dinge gemeinsam darstellen, so das ein Mensch den Zusammenhang erkennt” vs. "Dinge so koppeln, das eine Maschine das verwerten kann (grad die referenzielle Integrität) zu sehen. Und da gehe ich mit openzzz, das man die RI nicht immer braucht. Als Informatiker will man sie immer, aber man braucht sie nicht immer.
Das ist die GDI vs. “Wir speichern alles selbst”-Debatte. Bei behördlichen Geodaten ist man (auch aus politischen Gründen) bei GDIen angekommen. Man hat sich damit aber auch großen (hoffentlich einmaligen) Mehraufwand eingehandelt (bei der Harmonisierung und INSPIRE-konformen Abgabe der Daten).
Wie gesagt, die gibt es mit den OGC-Standards. Und mit ArcSchlagMichTot, dem proprietären ESRI-Standard.
Zur Anzeige. Nicht zur maschinellen Auswertung.
Ich nicht. Ich will OGC-konforme Geodienste, die ich dann bei mir mit anderen OGC-konformen Geodiensten lokal in meinem Quantum GIS verschneiden kann. Und eine schöne Karte. Aber da nehm ich, was da ist. Wenn ich ne Spezialkarte brauche, baue ich die selbst.
Im Brauhaus sollte man lieber nur Bier trinken und nicht mit dem Laptop herumspielen.
Ab einem gewissen Alkoholpegel kannst du Worte wie Geodateninfrastrukturen sowieso nicht mehr aussprechen.
Das Thema kommt jetzt mit den Kommunalwahlen in einigen Bundesländern wieder hoch.
Ich unterstütze diese Ansicht, denn es gibt einfach keine Grenze, da es sich nicht um eine Unterteilung von Landmasse, sondern eine möglichst gleichmäßige Verteilung von Wählern anhand ihrer Adresse handelt, da bleiben logischerweise große Teile des Gemeindegebietes (nämlich die unbebauten) undefiniert in ihrer Zugehörigkeit. Es werden innerhalb kleinster Ortschaften (jenseits aller admin-level) Unterteilungen vorgenommen. Das wird ganz deutlich, wenn man sich die Stimmbezirke für die Gemeinderatswahlen anschaut und da versucht eine Grenze zu ziehen, das dürfte in unbebauten Gegenden unmöglich sein, wenn die “Grenze” innerhalb eines Ortsteils liegt. Kriterium ist dabei nämlich nicht unbedingt eine Ortsgrenze bzw. kann es gar nicht sein, da dieser zu viele Stimmen hätte, nicht einmal eine Straße, sondern ein möglichst gleichmäßiger Verteilungsschlüssel der Bevölkerung über alle Stimmbezirke hinweg. Dass dann auf höherer Ebene diese Stimmbezirke zusammengefasst werden und man sich dabei an den Gemeindegrenzen orientiert kommt daher, dass die Gemeindeverwaltung die Wahlen organisiert und sich an ihren Zuständigkeitsgrenzen orientiert, außerdem sollen die Direktkandidaten natürlich für ein möglichst zusammenhängendes Stück gewählt werden.
Wie gesagt, Wahlkreisgrenzen als solche gibt es nicht, da hat EvanE Recht, auch wenn sich große Teile davon anhand vorhandener Grenzen vermuten ließen. Von daher gehören sie auch nicht in die Datenbank.
Unabhängig davon können wir die Straßenlisten natürlich weiter nutzen, um unsere Vollständigkeit zu überprüfen, aber das steht glaube ich nicht zur Debatte.
