wie wär’s mit einer Wochen-/Monatsaufgabe fuel:*?

Key:operator nun mit oder ohne Gesellschaftsform? Wiki empfiehlt ohne, wobei das wieder einmal so eine völlig unsinnige Kann-Regelung ist (denn es geht gerade nicht um Vielfalt beim Taggen).

Aber davon mal ganz abgesehen: Woher will man wissen, wer der Operator ist? Aus Steuergründen betreiben diese Unternehmen oft dutzende Tochtergesellschaften, die wiederum jede nur für einen Teil der Tankstellen zuständig ist. Ich würde deshalb mal behaupten, dass das größtenteils eine Falschinformation sein wird, weil sie auf reiner Spekulation fußt.

kreuzschnabel wrote:

• name=* wird nur dann gesetzt, wenn die Tankstelle einen echten Eigennamen hat
  

--ks

Ist ja grundzipiell richtig nur, dass operator kein Schw... auswertet, weder Smartie-App noch die Standard-Ansicht auf osm.org. Ich Blödmann draußen eine Notiz gemacht, nur um dann zu merken: einer hat "Shell" vom Namen nach Operator verschoben. Eine Note habe ich zu dem Thema auch schon gesehen.

Gruß Thomas

Thomas8122 wrote:

Ist ja grundzipiell richtig nur, dass operator kein Schw... auswertet, weder Smartie-App noch die Standard-Ansicht auf osm.org. Ich Blödmann draußen eine Notiz gemacht, nur um dann zu merken: einer hat "Shell" vom Namen nach Operator verschoben.

Zunächst: Operator wäre falsch, sondern prinzipiell gehört eine Bezeichnung wie "Shell", "OMV" oder "Aral" auf Key:brand, denn es ist eine reine Markenbezeichnung. Operator wäre das dahinterstehende Unternehmen, welches üblicherweise einen anderen Namen hat und zudem auch gar nicht unbedingt so leicht zu ermitteln ist.

Auch wird das durchaus ausgewertet. OsmAnd rendert beispielsweise diese Tankstelle als OMV, obwohl kein Name daran steht, sondern nur Brand getaggt wurde (Operator würde ohnehin auch erst als letzte Rückfallmöglichkeit genommen).

Und natürlich die alte Leier: Es wird nicht für den Renderer getaggt. 😉

Thomas8122 wrote:

kreuzschnabel wrote:

• name=* wird nur dann gesetzt, wenn die Tankstelle einen echten Eigennamen hat
  

--ks

Ist ja grundzipiell richtig nur, dass operator kein Schw... auswertet, weder Smartie-App noch die Standard-Ansicht auf osm.org.

Und daran wird sich auch nie was ändern, solange brav name=* dafür mißbraucht wird.

Seit wann schreiben wir semantisch falsches Zeug in die Datenbank, nur weil Autoren von Auswertern es nicht für nötig halten, die richtigen Tags auszuwerten? Fehler durch Gegenfehler auszugleichen war noch nie eine gute Idee.

--ks

Ich wollte bloß aufzeigen wohin das führt. Ich schrieb ja das es richtig ist.

Bevor die Diskussion føllig abgleitet: Meine einkliche Absicht war das Taggen der jeweils angebotenen Spritsorten. Ob im operator=* die Rechtsform dazugehört, finde ich ein wenig zweitrangig.

• snip kaputter code, siehe nächster post*
  

--ks

Irgendwie ist deine Anfrage vermurkst. Du überschreibst mit der Suche nach den Ways die Ergebnismenge der Nodes. Zudem werden zum Schluss völlig willkürlich Ergebnismengen rekursiert.

Ich habe das mal gefixt:

[out:json][timeout:25];

(
(node["amenity"="fuel"]({{bbox}});␣-␣node["amenity"="fuel"][~"^fuel:.+"~"."]({{bbox}}););
(way["amenity"="fuel"]({{bbox}});␣-␣way["amenity"="fuel"][~"^fuel:.+"~"."]({{bbox}}););
);

out␣body;
>;
out␣skel␣qt;

Danke, ja, das war Flickschusterei :-) hab irnkwas zusammengeschrieben, das zu funktionieren schien.

--ks

Ich kenne mich nun leider nicht im Detail mit den von Overpass verwendeten Datenbanken aus, aber ich habe mich gerade gefragt, ob man die Anfrage nicht noch etwas optimieren könnte:

[out:json][timeout:25];
(node["amenity"="fuel"]({{bbox}});␣-␣node[~"^fuel:.+"~"."];);
out␣body;

(way["amenity"="fuel"]({{bbox}});␣-␣way[~"^fuel:.+"~"."];);
out␣body;
>;
out␣skel␣qt;

Man braucht kein Union konstruieren, sondern kann Nodes und Ways einfach hintereinander ausgeben. Das funktioniert auch.

Aber die Differenz funktioniert auf diese Weise nicht sonderlich gut (sehr viel langsamer bzw. Timeout), was darauf schließen lässt, dass für den Subtrahenden Anfragen über die Gesamtdatenbank laufen. Dabei dürfte das unnötig sein, denn die Ergebnismenge kann bei Differenz nicht größer werden als der Minuend. Also wäre es doch sinnvoll, dass man für den Subtrahenden keine neue Gesamtdatenbankabfrage durchführt, sondern einfach nur im Speicher auf der Ergebnismenge des Minuenden operiert. Denn die ist viel kleiner und damit schneller zu prozessieren als die Gesamtdatenbank. Damit wäre es aber wiederum sinnlos, beim Subtrahenden nochmals die gleichen Abgleiche wie ["amenity"="fuel"] oder ({{bbox}}) durchzuführen, denn diese Beschränkungen sind durch den Minuenden schon vorgegeben. Aber so funktionert es eben offenbar nicht.

Besser als wie folgt, scheint es also nicht zu gehen:

[out:json][timeout:25];

(node["amenity"="fuel"]({{bbox}});␣-␣node["amenity"="fuel"][~"^fuel:.+"~"."]({{bbox}}););
out␣body;

(way["amenity"="fuel"]({{bbox}});␣-␣way["amenity"="fuel"][~"^fuel:.+"~"."]({{bbox}}););
out␣body;
>;
out␣skel␣qt;

Kontinentalverschieber wrote:

Also wäre es doch sinnvoll, dass man für den Subtrahenden keine neue Gesamtdatenbankabfrage durchführt, sondern einfach nur im Speicher auf der Ergebnismenge des Minuenden operiert. Denn die ist viel kleiner und damit schneller zu prozessieren als die Gesamtdatenbank. Damit wäre es aber wiederum sinnlos, beim Subtrahenden nochmals die gleichen Abgleiche wie ["amenity"="fuel"] oder ({{bbox}}) durchzuführen, denn diese Beschränkungen sind durch den Minuenden schon vorgegeben. Aber so funktionert es eben offenbar nicht.

Das ist richtig, beide Queries werden unabhängig voneinander ausgeführt. Am besten dazu einen Enhancement request aufmachen unter https://github.com/drolbr/Overpass-API/issues

Prinzipiell würde dieser Ansatz auch heute schon mit einem ._ funktionieren, wie im folgenden Beispiel zu sehen (link). Das bringt nochmal etwa 15% Laufzeitverbesserung, natürlich abhängig von der bbox:

(node["amenity"="fuel"]({{bbox}});␣-␣node._[~"^fuel:.+"~"."];);
out␣body;

(way["amenity"="fuel"]({{bbox}});␣-␣way._[~"^fuel:.+"~"."];);
out␣body;
>;
out␣skel␣qt;

Generell würde ich vorschlagen, für Laufzeitmessungen aktuell eher die frz. Instanz (api.openstreetmap.fr/oapi/) zu nutzen, in overpass turbo zu finden unter "Einstellungen" -> "Server", hier den dritten Eintrag auswählen.

Dort läuft schon die gerade aktuelle Version 0.7.53, allerdings ohne attic.
Laufzeitprobleme auf älteren Versionen sind nicht mehr so wirklich aussagekräftig.

Gut, wir ändern meinen Wochenaufgabenwunsch in „Overpass-Abfragen optimieren“. Für das Taggen von Spritsorten besteht offenbar nicht der geringste Bedarf.

• sigh*
  

--ks

mmd wrote:

Am besten dazu einen Enhancement request aufmachen unter https://github.com/drolbr/Overpass-API/issues

OK, ich war mal so frei.

kreuzschnabel wrote:

Gut, wir ändern meinen Wochenaufgabenwunsch in „Overpass-Abfragen optimieren“. Für das Taggen von Spritsorten besteht offenbar nicht der geringste Bedarf.

Sieh es doch positiv: Du konntest durch deine Aufgabe sogar noch zusätzliche Dinge bewirken - nämlich verborgenes Optimierungspotenzial in Overpass aufdecken. Das schafft nicht jeder mit einer Aufgabenstellung.

kreuzschnabel wrote:

• name=* wird nur dann gesetzt, wenn die Tankstelle einen echten Eigennamen hat
  

--ks

Für mich ist "Shell" der Name einer Tankstelle. So wie auch Supermärkte "Aldi" heissen, Restaurants "Burger King" und Hotels "Hilton". Das sind alles eigentlich nur brand=*. Ich verwende das auch so im Sprachgebrauch, wenn ich bei "der Agip" war und nicht bei "der Tankstelle, die Agip-Produkte vertreibt".

Kontinentalverschieber wrote:

Operator wäre das dahinterstehende Unternehmen, welches üblicherweise einen anderen Namen hat und zudem auch gar nicht unbedingt so leicht zu ermitteln ist.

operator=* würde ich auch vermeiden. Wir werden es nicht schaffen, die Beziehung zwischen dem Geschäftsführer / Eigentümer / Pächter und der Ölgesellschaft rauszubekommen. Die Ölgesellschaft ist auch schwer zu ermitteln und eher sinnlos zu taggen. Bei Pächtern müsste die auf der Rechnung stehen, wenn man Benzin kauft und keine Schokoriegel. Bei angestellten Geschäftsführern auch bei Schokoladenrechnungen. Bei Eigentümern ist eben dieser der Betreiber, nicht der Ölkonzern.

Grüße
Max (ehemaliger Pächtersgatte 😉 )

kreuzschnabel wrote:

... Für das Taggen von Spritsorten besteht offenbar nicht der geringste Bedarf...

Jein. Es ist halt unbefriedigend Dinge zu erfassen, die standardmäßig erwartet werden. Diesel und Benzin kriegt man halt "immer". Und diejenigen, die Gas- oder Elektroautos fahren, sind nicht viele ;-)
Die Aufgabe wäre halt leichter, wenn man weniger verbreitete Dinge erfassen/prüfen soll - dann ist man auch schneller fertig.

maxbe wrote:

Für mich ist "Shell" der Name einer Tankstelle. So wie auch Supermärkte "Aldi" heissen, Restaurants "Burger King" und Hotels "Hilton".

+1 ... und für alle die, die bisher immer das Argument "in name gehört das, was an dem Gebäude steht" - und das ist bei den von maxbe genannten nun mal der Fall -, brauchen jetzt gar nicht widersprechen 😉

PS: Auch wenn ich als Softwareentwickler Redundanzen ungern sehe, so habe ich bei den paar handvoll Tankstellen neben den fuel-Sorten - um die es hier geht - eben auch redundant name, brand und Co erfasst.

pyram wrote:

Jein. Es ist halt unbefriedigend Dinge zu erfassen, die standardmäßig erwartet werden. Diesel und Benzin kriegt man halt "immer". Und diejenigen, die Gas- oder Elektroautos fahren, sind nicht viele ;-)

Ja, dem mag vielleicht jetzt zu diesem Punkt so sein ... aber was ist in ein paar Jahren, da kann sich das Verhältnis auch schneller als uns allen lieb ist drehen ... also warum auch nicht hier "Vorreiter" in der Datenerfassung und -pflege (!) sein.

... die Aufgabe das könnte man noch um charging_station erweitern.

pyram wrote:

Es ist halt unbefriedigend Dinge zu erfassen, die standardmäßig erwartet werden. Diesel und Benzin kriegt man halt "immer".

• kicher* Ich bin heute während meiner Tankstellenerkundungsfahrt (die noch viele Fehler offenbarte – http://www.openstreetmap.org/node/3966462517 war als Dieseltanke getaggt!) in 105 km über Land an immerhin drei reinen Autogas-Tankstellen vorbeigefahren, die als normale amenity=fuel in der Datenbank stehen, wo du aber weder Benzin noch Diesel kriegst. Da stehst dann nämlich zur Abwechslung du davor und guckst komisch, nicht ich.
  

Viele Autohäuser oder Vertreiber technischer Gase stellen sich eine Autogastankstelle auf den Hof, weil sie wirklich nur hingestellt werden muß – da kann ja unter Normalbedingungen nichts Flüssiges ins Grundwasser sickern, deshalb fällt der ganze Aufwand mit Ölabscheider und so weiter weg, den eine normale Tanke braucht. Zahlung per EC-Karte, 24/7 geöffnet, geringe Investition, langfristiges Geschäft, gerade in schwächer strukturierten Gegenden.

Nenee, die Spritsorten gehören für mich an eine Tankstelle ebenso wie die Leerungszeiten an einen Briefkasten.

--ks

Mir fehlt ein tag "Es gibt nur den getaggten Brennstoff." Dann bräuchte man für eine reine Gas-Tankstelle nicht unzählige Male "no" angeben.

Baßtölpel

Hallöchen :-)

wird damit angegeben ob sie Gas haben, oder auch ob sie das verkaufen.

<<<Hamburg. Aral, Shell, Esso, Jet, Total – die großen Tankstellenketten in Deutschland haben den Pächtern und Betreibern ihrer Stationen empfohlen, Kunden vorübergehend kein Erdgas mehr zu verkaufen. Zuvor war es zu einem schweren Unfall beim Betanken eines Erdgasautos gekommen. Das Abendblatt beantwortet die wichtigsten Fragen zu den Gründen und den Folgen des Verkaufsstopps.>>>
http://www.abendblatt.de/hamburg/articl … anken.html

das aktuell zu halten wird ne Mammutaufgabe

Nun ja, soviele Erdgastankstellen gibt es nun auch wieder nicht. Bei Flüssiggas sieht’s anders aus.

Göre wrote:

das aktuell zu halten wird ne Mammutaufgabe

Vorübergehende Maßnahmen werden nur selten in OSM erfaßt. Wenn eine Straße zwei Wochen lang gesperrt ist, nimmst du sie ja auch nicht aus der Datenbank raus. Darin sehe ich nun wirklich keinen Hinderungsgrund. Wir müssen unsere Daten nicht tagesaktuell halten.

Da kannst du genausogut gegen das Erfassen von Briefkästen argumentieren, weil die auch alle paar Jahre abgebaut werden oder sich deren Leerungszeiten ändern.

Wenn eine Tanke eine Erdgaszapfstelle hat, schreiben wir fuel:cng=yes dran, auch wenn jetzt zwei Wochen lang Verkaufsstopp ist (den ich, nebenbei, komplett unsinnig finde – seit Jahren fahren Tausende von Erdgasautos störungsfrei auf unseren Straßen, und jetzt platzt einmal ein Tank, schon tun alle, als sei das Erdgas eine Erfindung des galaktischen Imperiums, um die Investition für den Todesstern einzusparen. Wird auch der Verkauf von Motorsägen komplett eingestellt, sobald einer mal damit verunglückt?). Autogas betrifft das übrinx nicht, 5 bar Druck im Tank sind leichter zu händeln als 200.

--ks

Basstoelpel wrote:

Mir fehlt ein tag "Es gibt nur den getaggten Brennstoff." Dann bräuchte man für eine reine Gas-Tankstelle nicht unzählige Male "no" angeben.

Ließe sich das als „fuel=lpg“ abbilden? Die „Schalter“ per Suffix sind doch nur dazu da, mehrere Werte angeben zu können. Aber wahrscheinlich wertet das wieder keine Software aus.

Oder hintenrum, wie bei access: fuel=no + fuel:lpg=yes. Das kömmt mir sauberer für.

--ks

Eigentlich ist das unnötig. Es reicht vollkommen aus, das zu taggen, was es gibt. Im Umkehrschluss gibt es das, was nicht getaggt ist, entsprechend nicht.

Und wo es bisher nur vergessen oder noch gar nicht erfasst wurde, wäre es ja ohnhin nicht zuzusichern. Zumal man als zusätzliche Hilfestellung zur Beurteilung der Situation den Sachverhalt hätte, ob überhaupt irgendein fuel-Key erfasst ist. Denn die Wahrscheinlichkeit, dass jemand nur eine einzelne Sorte erfasst, wenn es x weitere Sorten gäbe, ist ja doch relativ gering. Spätestens also, wenn bestimmte Sorten gelistet sind und andere nicht, darf man davon ausgehen, dass es die nicht geben wird. Und der verschwindende Rest fällt ohnhin unter den Umstand, dass in regelmäßigen Abständen die Daten auf Aktualität zu prüfen sind.

Kontinentalverschieber wrote:

Und wo es bisher nur vergessen oder noch gar nicht erfasst wurde, wäre es ja ohnhin nicht zuzusichern. Zumal man als zusätzliche Hilfestellung zur Beurteilung der Situation den Sachverhalt hätte, ob überhaupt irgendein fuel-Key erfasst ist. Denn die Wahrscheinlichkeit, dass jemand nur eine einzelne Sorte erfasst, wenn es x weitere Sorten gäbe, ist ja doch relativ gering. Spätestens also, wenn bestimmte Sorten gelistet sind und andere nicht, darf man davon ausgehen, dass es die nicht geben wird.

Ich muß dich da leider eines Besseren belehren. Gerade der Umstand, daß Diesel und Super an fast jeder Tanke verfügbar sind, LPG aber nicht, führt dazu, daß ich immer wieder mal auf normale Tankstellen stoße, die als einzige explizit getaggte Spritsorte fuel:lpg=yes aufweisen. Die „normalen“ Sorten schienen dem Kollegen wohl nicht der Rede wert zu sein, nur der Sachverhalt „LPG gibt’s auch“ wurde getaggt. Auf der Suche nach einem Beispiel bin ich gerade ziemlich schnell auf http://www.openstreetmap.org/way/96055363 gestoßen, auch Am Hockenheimring Ostseite scheint man nichts anderes zu bekommen.

Damit ist aber eine solche Tanke im Tagging nicht mehr von einer zu unterscheiden, die wirklich nur LPG führt! Deshalb mache ich mir die Mühe, alle nicht geführten Sorten in der JOSM-Vorlage ausdrücklich abzuwählen (fuel:adblue fehlt da noch, aber wer keinen Diesel anbietet, braucht auch keinen Harnstoff zu verkaufen).

Im Übrigen müssen wir diese Überlegungen nicht auf die Randgruppe¹ der Gasfahrer beschränken. Auch wer mindestens ROZ 98 braucht oder will, kann bei weitem nicht mehr an jeder Dorftanke bedient werden, dort gibt es meist Diesel, Super und E10.

--ks

¹ Ich werde nie verstehen, warum kein höherer Anteil von Fahrern auf die Idee kommt – die Propaganda à la „Gas macht jeden Motor kaputt“ ist wohl ebenso tiefsitzend wie grundfalsch. Für mich war schon lange klar: Wenn ich von Diesel abspringe, kommt Autogas ins Haus.

kreuzschnabel wrote:

Im Übrigen müssen wir diese Überlegungen nicht auf die Randgruppe¹ der Gasfahrer beschränken. Auch wer mindestens ROZ 98 braucht oder will, kann bei weitem nicht mehr an jeder Dorftanke bedient werden, dort gibt es meist Diesel, Super und E10.

1:50 und 1:33 (zumindest letztes Jahr hab ich ne Tanke gesehen die auch noch 1:33 führt) fehlen da auch noch ...

was ne Wochenaufgabe betrifft: in meinem mit Moped bequem erreichbaren Umfeld ist alles eingetragen ...

MKnight wrote:

1:50 und 1:33 (zumindest letztes Jahr hab ich ne Tanke gesehen die auch noch 1:33 führt) fehlen da auch noch ...

1:50 gips in der JOSM-Vorlage.

--ks

Stolpere gerade über http://www.openstreetmap.org/way/137611336 – eine normale Shelltanke, an der nur cng=no und lpg=yes getaggt ist. Quelle: gas-tankstellen.de. War das ein Import? Dann ist es verständlich, man hat halt an alle Gastankgelegenheiten lpg=yes getaggt, und über das jeweilige übrige Spritangebot lag ja keine Information vor.

--ks

PS: Jaaa, ich war wieder zu schnell … machen wir noch nen Tee …
PPS: Immer noch nicht, muß man denn immer auf die Uhr schauen, um auch ja zwei Minuten zu brauchen?

Ja, das war ein Import. Und so sieht das in Overpass aus.

Jojo4u wrote:

... die Aufgabe das könnte man noch um charging_station erweitern.

Bezüglich der Ladestationen verweise ich mal auf diesen Thread:

http://forum.openstreetmap.org/viewtopic.php?id=54928

Gruß Klaus

Ich fände es sinnvoll, einmal einen Verbraucherinformationsdienst wie clever-tanken.de anzufragen, ob man die Informationen über das Spritangebot und eventuell auch Zusatzinformationen wie Öffnungszeiten von dort nach OSM übernehmen kann. Laut deren Website bedarf das der ausdrücklichen Genehmigung (ist also schon mal nicht a priori verboten).

Hat es so eine Anfrage schon mal gegeben, bevor ich mir die Mühe vergeblich mache?

--ks

kreuzschnabel wrote:

Hat es so eine Anfrage schon mal gegeben, bevor ich mir die Mühe vergeblich mache?

Ich weiß es nicht, ob es eine solche Anfrage bereits gab, allerdings kann man sich die Mühe aus einem anderen Grund sparen. Diese Portale beziehen ihre Informationen von der Markttransparenzstelle für Kraftstoffe. Diese Daten unterliegen aber den in § 7 (1) MTSKraftV genannten Bedingungen. Diese Portale haben also gar keine Möglichkeit, die von der Markttransparenzstelle bereitgestellten Tankstellengrunddaten für uns lizenzgerecht weiterzugeben, weil beispielsweise absolute Änderungsverbote gelten.

Kontinentalverschieber wrote:

allerdings kann man sich die Mühe aus einem anderen Grund sparen

Ah, danke. Ich hätte in meiner Anfrage erwähnt, daß wir nicht die für das jeweilige Portal eigentlich relevanten Daten, nämlich die Preisinformationen, übernehmen, sondern nur die Metadaten über die Tankstellen. Also die „Grunddaten“. Aber wenn schon die MTS-K das so restriktiv handhabt, ist das für uns tatsächlich nicht nutzbar. Muß ich halt weiter rumtelefonieren oder die Atmosphäre mit Erkundungsfahren verdrecken, zum Glück verbrennt fuel:lpg ziemlich sauber :-)

--ks

Wenn ich nichts missverstanden hab, dient die Wochenaufgabe doch dazu, strategisch für das OSM Projekt wichtige Dinge gemensam anzugehen.

Die Frage ist ob dass die Sorten än den Tänkstellen sind oder nicht.

Ich tendiere zu einen Nein, vorallem deswegen weil die Information durch Datenkombination sich leichter erschliessen lässt.

Alleine bei Biokraftstoffen für Dieselmotorer wirds unübersichtlich: Es gibt Biodiesel, reinrs Rapsöl, HVO100 Und noch so einiges mehr...

Wenn man schön die Sorten erfasst wäre es auch sinnvolle Adblue Angebot zu erfassen (das Zeug für die Abgasreinigung von Dieselautos Und LKW)

Skinfaxi wrote:

Wenn man schön die Sorten erfasst wäre es auch sinnvolle Adblue Angebot zu erfassen (das Zeug für die Abgasreinigung von Dieselautos Und LKW)

fuel:adblue=* existiert. Wobei das semantisch schräg ist, denn Adblue ist kein Brennstoff.

--ks

kreuzschnabel wrote:

fuel:adblue=* existiert. Wobei das semantisch schräg ist, denn Adblue ist kein Brennstoff.

Und die nächste Frage, die sich dabei stellt: Sollte man das nur taggen, wenn es eine eigene Zapfsäule für AdBlue gibt oder reicht es auch, wenn die Tankstelle das in Kanistern verkauft (was vermutlich fast jeder Tankstellenshop tun dürfte)? Wenn nur an der Zapfsäule: Dort scheint es wiederum Unterschiede für das Auffüllen bei LKW und bei PKW zu geben. Wäre damit nun ein Zapfanlage für LKW oder für PKW gemeint?

AdBlue ist schon deshalb zweitrangig, weil die davon betroffenen Fahrzeuge AFAIK auch ohne das Zeux erstmal weiterlaufen, wenn auch mit gedrosselter Leistung. Davon wird wenig gebraucht, man hat üblicherweise ausreichend Harnstofflösung dabei.

--ks

Skinfaxi wrote:

Ich tendiere zu einen Nein, vorallem deswegen weil die Information durch Datenkombination sich leichter erschliessen lässt.

Was meinst du damit? Durch welche Kombination welcher Daten? Von Online-Quellen? Ich saß letztes Wochenende in einem Landgasthof 5 km von einer deutschen Mittelstadt entfernt in einer einklich nicht strukturschwachen Gegend. Mobilfunk-Datennetz: Nicht der Rede wert. Da brauchst du gar nicht nach Tankstellen zu googeln, das läuft in einen Timeout.

Die OSM-Datenbank kann diese Informationen vorhalten, Navis werten sie schon längst aus. Die Kraftstoffsortimente von Tankstellen ändern sich weniger häufig als die Leerungszeiten von Briefkästen, die ich etwa an jedem dritten ändere, den ich überprüfe. Sollen wir die Leerungszeiten dann auch weglassen? Arztpraxen werden eröffnet, geschlossen, umgesiedelt. Sollen wir aufs Mappen von Arztpraxen verzichten, weil man die Information ja auch woanders herbekommt?

Es ist eine Stärke von OSM, daß ich all diese nicht ganz kurzlebigen Informationen offline während einer Fahrt oder Reise verfügbar haben kann. Es ist eine Stärke, daß mir ein OSM-basiertes Navi unterwegs den Weg zur nächsten Tanke zeigen kann, die Super Plus hat. Oder halt Erdgas, oder sonstwas. Ohne erst Online-Quellen anzapfen und Geopositionen copypasten zu müssen. Ich bin prinzipiell dafür, diese Stärke auszubauen.

--ks

Frage am Rande:
Gerade letzthin wurde ich wieder gefragt, ob es nicht ein App gäbe für iOS und Android, um offline Tankstellen zu erfassen?
Wer einmal z.B. in Kuba war, weiss woher dieser Wunsch kommt...
Das ist eine altbekannte Frage ich weiss, deren Lösung aber auch anderen POIs in OSM zu Gute käme :-)

Geonick wrote:

Frage am Rande:
Gerade letzthin wurde ich wieder gefragt, ob es nicht ein App gäbe für iOS und Android, um offline Tankstellen zu erfassen?
Wer einmal z.B. in Kuba war, weiss woher dieser Wunsch kommt...
Das ist eine altbekannte Frage ich weiss, deren Lösung aber auch anderen POIs in OSM zu Gute käme :-)

OsmAnd - wie immer meine erste Wahl. "Draussen" mit Offline-Karte erfassen und @home hochladen.

Geonick wrote:

Gerade letzthin wurde ich wieder gefragt, ob es nicht ein App gäbe für iOS und Android, um offline Tankstellen zu erfassen?

"Go Map!!" ist für iOS die erste Wahl. Vorort mit der Live-Datenbank erfassen und gleich hochladen oder offline/offline arbeiten. Ist für POI etwas overkill aber ein relativ vollwertiger Editor (außer für Relationen) und kann beliebige TMS-Layer als Hintergrund nutzen.