Mapping der Spritpreise auf den Tankstellen

Du bist fantastisch Joachim :wink:
Da kann ich kurz berichten was sich so in Polen tut:
Der befreundete OSM User und Inhaber der Firma die via GPS Leihfahrzeuge und Dienstwagen beobachtet, hat in seinen Daten selbst die Orte wo getankt wurde und die aktuellen Preise dafür.
Da die Daten mit einer leichten Verzögerung an ihne geliefert werden, kann er einen Durchschnittswert bilden und anzeigen: Billiger als der Landesdurchschnitt, Landesdurchschnitt, teurer als der Landesdurchschnitt, am teuersten (teuersten 3% der Tankstellen).

Hallo Marek,

ich habe bewusst nur nach den Stammdaten wie Name, Adresse, Geokoordinaten, Öffnungszeiten, … und natürlich der Tankstellen-ID nachgefragt. Die Preise sind mir momentan egal, darum sollen sich andere App-Anbieter oder Projekte kümmern. Durch die ID und/oder Geodaten können diese dann gerne die Preise auf einer OSM-Karte darstellen oder per API zur Verfügung stellen, falls dies rechtlich zulässig ist.

Grüße
Joachim

Das hat definitiv nichts in OSM zu suchen. Ich frage mich wirklich ernsthaft wie man überhaupt auf so eine Idee kommen kann Spritpreise zu erfassen in den Karten.
Anscheinend gibts hier genug Leute, die den ganzen Tag nichts anderes zu tun haben:D
Ich hatte es schon einmal gepostet-teilweise werden sogar Papierkörbe und sonstiger Kleinkram hier gemappt. Wird einmal eingetragen und dann wars das-das Jahr drauf isses weg und die Daten sind immer noch erfasst.

**Um es einfach auszudrücken-manchmal ist weniger mehr.
**
Das wird einfach zuviel an Daten, die mit Sicherheit bei solchem “Firlefanz” nicht aktuell gehalten werden können.
Ich habe schon genug damit zu tun mein Gebiet zu erweitern und zwar so das es halbwegs aktuell gehalten werden kann.
Solange bin ich jetzt auch noch nicht in Openstreetmap tätig, aber ich hoffe doch sehr, das ich mit meiner Meinung des Pudels Kern treffe.
LG Volker

Hallo Joachim,
es ist auch richtig.
Somit hätte man aber eine Grundlage für ein solches Projekt.
Grüße,
Marek

Jo, dann geht halt der nächste durch und schmeisst es raus. Find ich gut. Mach ich grade bei Briefkästen hier.

Klar muss man auf Aktualität prüfen, aber das muss man halt.

Trotzdem finde ich Daten, die sich inhärent mindestens einmal am Tag ändern, für die OSM zu kurzlebig. Das sollen andere, verbundene Dienste anbieten. Auf den Trichter ist man im Geobereich jha auch schon seit einem Jahrzehnt gekommen. Geodateninfrastruktur ist da das Stichwort; dezentrale Datenhaltung und vernetzung.

Äh… meinen ersten GPSr habe ich zwar schon 2001 gekauft, aber so lange bin ich noch nicht bei den Mappern :wink:

sehr OT:

Das nächste mal™ nehme ich als meinen Usernamen “aaargh” und melde mich dann auch immer :wink:

Um zum Thema zurückzukommen: Der Ruf “macht das doch in einer externen Datenbank” erschallt zum Glück häufig für flüchtige Daten, die weniger mit Kartographie als mit Geolokalisation zu tun haben, aber im Prinzip keine, oder nur geringe Anforderungen an eine Versionshistorie stellen.

Meiner Meinung nach wäre es wünschenswert, wenn es dafür EIN(!) Opendata-Projekt geben würde, was solche Sachen unter seine Fittiche nehmen würde, solange es nicht total den Rahmen sprengt.
Einfach damit nicht das Rad x-mal neu erfunden werden muss. Und damit potentiell freie Daten auch unter freier Lizenz auf breiter Front für Leute verfügbar bleiben für Leute, die auf mehreren aufbauend abstrahieren wollen.

Das wäre eine schöne Sache. Welche andere Themen fallen dir dafür spontan ein?
Grüße,
Marek

[…Opengeodata-Overlay…]

  • (Bundestags-)Wahlkreise
  • Mobilfunkabdeckungen
  • DSL-Verfügbarkeiten
  • Strom/Gas-Grundversorger
  • Bannmeilen und “Gewerbe-Sperrgebiete”
  • offizielle “Kriminalitätsschwerpunkte” (vgl. verdachtsunabhängige Personenkontrollen), eine Städte dokumentieren gemäß Auflagen öffentlich
  • Jagdreviergrenzen (Bei Hegeringen)
  • 2Müllfahrzeug-Wochentage"
  • Kabeltv-Versorger

Was nicht hineingehört: Listen/Datenbanken, die sich an bestehenden Landkreis/Gemeindegrenzen scheiden und so einfacher “erschlagen” werden können.
Dafür würde ein einfacher Geocoder reichen, um dann über den Umweg “Gemeinde XY” zu erfahren, zu welchem Recyclinghof das Gebiet gehört.

Was sind technische Voraussetzungen um das auf die Beine zu stellen?
Da ich seler kein Programmierer bin: Ist das Thema genug für eine Masterarbeit?

(Ich würde das erst Mal testsweise auf DE, AU, CH, PL beschränken, damit man verschiedene Länder drin hat.)

Kommt auf die Bearbeitungszeit drauf an. Masterarbeiten können ja auch recht kurz ausfallen.
Im Prinzip ist es aber eher eine Aufbereitung der Daten.

Mit Sicherheit kann man daraus eine Abschlussarbeit machen. Ala “Entwicklung eines Datenbankschemas und einer API für <oben aufgeführte Objekte>…” Ob das allerdings sinnvoll ist, ist eine andere Frage. Denn irgendwer muss das hinterher auch pflegen und vorallem betreiben. Wenn sich keine Admins bzw. Devs finden, die Hinter dem Projekt stehen, dann ist das Ganze im Prinzip schon gestorben, bevor es geboren wurde.

Ich möchte hier mit der TU Lodz sprechen. Die sind so ziemlich OSM nahe, daher will ich´s mal versuchen. Und die Idee finde ich nett. Allerdings bräuchte ich von Euch ein Wenig Input was man sich vorstellen könnte (danke -jha-) und wie, von wem man die Daten beziehen kann. Es ist insbesondere deswegen wichtig, weil die Daten aus DE von einem Admin aus Polen betreeut wären (wenn´s klappt).

Ich glaube nicht dass “wir suchen einen Admin” (oder auch nur "wir suchen einen Server) auch nur mittelfristig bei so einem Projekt anstünde.
Da wäre erstmal sehr viel Grundlagenarbeit notwendig, sie die Datenbanken überhaupt aussehen sollen und was die API zu leisten hat. Und dann müsste man sich intensive Gedanken machen, wie die Spielregeln sein sollen (=“Anspruchsgrundlage wer gegenäber wem”, “wer darf ggf. auch sagen 'nee, das wollen wir(?) nimmer hier drauf haben.”, “wie voluminös darf ein Projekt werden”, “was ist überhaupt ein(!) Projekt”)
Über Lizenzen wird man sich auch nachdenken müssen.

Dann Datenlieferanten zu finden wird dann schon fast Zukunftsmusik.

Naja, im Zusammenhang mit einer externen Datenbank gibt es sicher einige ungelöste Probleme:

  • Zur Koppelung an die OSM-DB ist die OSM-Objekt-Id nicht geeignet,
    da sie nicht garantiert werden kann.
  • Was ist mit Objekten, die nicht in der OSM-DB enthalten sind?
  • Wie geht man mit Veränderungen von Objekten um (Splitten/Zusammen-
    fassen von Wegen/Flächen)? Ich habe in den letzten Wochen ein großes
    Wald-MP in drei handlichere zerlegt und viele kleinere MPs zu einfachen
    Flächen umgebaut.
  • Wie mit der Umwandlung von Punkt- zu Flächen-POI umgehen?
  • Wie geht man mit unterschiedlichen, ggfs. konkurrierenden Datenquellen um?
    Jede hat ihre eigenen Anforderungen, IDs und Regeln.
  • Viele weiteren Fragen, die sich im Laufe der Implementierung ergeben.

Die Koppelung ist im allgemeinen Fall in der Regel nicht trivial. Insbesondere wenn man etwas wie historische Entwicklungsstadien von Straßen-/Eisenbahn-Netzen, Städten oder Burgen betrachten will. Im konkreten Fall Spritpreise kann man sich mit einer externen Referenz-Nummer an den OSM-Tankstellen helfen. Aber ob das in allen Fällen sinnvoll oder einfach sein würde, bleibt bisher eine offene Frage.

Ob so etwas als Thema für eine Masterarbeit reicht, hängt von der Fragestellung ab. Bei einer Implementierung von Spritpreisen vielleicht nicht. Wenn das Thema aber allgemeiner “Kopplung externer Datenbanken an OSM anhand mehrerer Szenarien” lautet, dann scheint mir das gegeben.

Aus Sicht von OSM ist die Frage, was hinterher mit den erarbeiteten Ergebnissen passiert (wie aighes nachfragte), also insbesondere ob daraus ein funktionierender Dienst durch die Uni oder andere entsteht, sehr viel bedeutender, als die Erarbeitung eines Lösungsansatzes.

PS: Rein zur flächenmäßigen Abrundung würde ich noch die Tschechei dazu nehmen.

Edbert (EvanE)

Hallo Edbert,

Die bleibt aber in der History, oder?

Sowas soll vermieden werden. Daten die ins OSM passen, gehören ins OSM. Der Rest ist uns Wurscht. Oder?

Wöchentliche Updates der OSM DB? Müsste wahrscheinlich reichen.

Müsste man im Detail sehen.

Dito. Wir wissen noch nichts, da wir noch nicht angefangen haben. Somit sind keine konkrete Beispiele vorhanden. Es wäre wohl ein Thema für eine Diplomarbeit…

Das Konzept in dem sich temporäre Daten in einem offenen Projekt ( auf der OSM Grundlage) darstellen lassen, klingt spannend. Genauso wie OSM zu Anfang. Damals wusste man auch keine Antworten auf viele Fragen. Man muß halt damit beginnen.

In PL haben wir schon Was für die Spritpreise. In DE müsste man weiter überlegen wie man´s am schlausten machen könnte.

Und was nutzt die History? Das Objekt ist schlicht nicht mehr in den OSM-Daten vorhanden.
Das kann jetzt mehrere Dinge bedeuten:

  • Das Objekt existiert nicht mehr in der Realität
  • Das Objekt wird jetzt durch ein anderes OSM-Objekt repräsentiert.
    z.B. Punkt wird durch eine Fläche ersetzt (Parkplatz, Adresse, …)
  • Das Objekt existiert weiter in der Realität aber nicht mehr in OSM.
  • Das Objekt wurde mit einem anderen OSM-Objekt vereinigt,
    existiert also unter einer anderen OSM-Id weiter.

Umgekehrt geht es auch. Nehmen wir eine kleines Gebäude (z.B. 20" Container) auf dem Parkplatz eines Baumarktes. Im Dezember wird das für den Weihnachtsbaum-Verkauf genutzt. Im Januar/Februar für Schlussverkauf-Reste. Im Frühjahr als Kiosk, im Sommer/Herbst als Frittenbuden. Das ist immer das Objekt mit der gleichen OSM-Id aber repräsentiert ganz unterschiedliche Objekte der realen Welt.

Keine gute Antwort, Beispiel Spritpreise. Wir haben zwar die meisten Tanken erfasst, jedoch sicher nicht alle. Was machen wir mit dem Rest? Sofern wir Geo-Koordinaten im Datensatz haben, können wir es trotzdem darstellen. Drüber hinaus können wir auch eine Differenz-Liste externe Daten - OSM erstellen und damit die Stellen finden, die noch fehlen bzw. eventuell keine Tanken mehr sind.

Das ist ja nur die technische Seite des Problems. Der Rhytmus hängt ggfs. auch von den externen Daten ab.

Aber das war nicht mein Punkt. Was ist mit Nutzung → Leerstand → andere Nutzung usw.
Oder mit “In externer Liste” → “Nicht (mehr) in externer Liste”.

Genau an dem Beginnen knabbern wir im Augenblick.
Man wird da sicher vieles erst nach und nach erkennen und dann entsprechend nacharbeiten.

Edbert (EvanE)

Sehr kurz da ich auf Dienstreise muß und erst morgen Abend erreichbar bin:
Ich danke Dir dass Du hier ein Sparringpartner bist.
Veruchen wir´s Mal gemeinsam mit dem Anfang. Probleme bekommen wir noch genug zu lösen.
Aber das macht u. A. die Sache so spannend.

Beste Grüße!
Marek

Hallo Joachim,

Da wir ja jetzt schon seit einigen Wochen eine neue Regierung haben und die Bundesministerien wieder entscheiden dürfen :), würde mich interessieren, ob sich bezüglich der Tankstellen-Daten etwas bewegt hat. Fallen Tankstellendaten nach Meinung der Behörde unter die GeoNutzV (Verordnung zur Festlegung der Nutzungsbestimmungen für die Bereitstellung von Geodaten des Bundes), nach der bundeseigene Geodaten offenzulegen sind?

Viele Grüße

Michael

EDIT: Langschreibweise der GeoNutzV korrigiert