Briefkästen in HH-Wandsbek aktualisiert

Wahrscheinlich hat die Post einfach die letzte Lücke in den Auflagen der Bundesnetzagentur gefunden und ausgenutzt:http://www.welt.de/wirtschaft/article122465472/Post-erhoeht-Porto-zum-zweiten-Mal-in-12-Monaten.html. Aufmerksame Mapper merken es trotzdem :smiley:

Welcher eingeschränkte Service?

Die morgens geleerten Briefe landen heutzutage mit den abends geleerten Briefen im gleichen LKW zum nächsten Hub. Inzwischen sind die Sortieranlagen so leistungsfähig und schnell, daß eine mehrmalige Leerung keinen Sinn mehr macht, außer der Briefkasten ist so frequentiert daß er überquillt. Die mehrmals täglichen Leerungen stammen noch aus der Zeit der Handsortierung.

Inzwischen sind Leerungszeiten einfach auf die Logistik abgestimmt, d.h. ein bis zur Leerung eingeworfener Brief ist in den meisten Fällen am nächsten Tag am Bestimmungsort.

Am Briefporto wirst Du nicht abgezockt, da hab mal lieber ein Auge auf Strom und Wasser :wink:

Hallo,

bei Objekten, die sich ab und zu ändern, ergänze ich ein last_checked=yyyy-mm-dd.

viele Grüße

Dietmar

Hallo Dietmar,

in Hamburg wird dafür bei Briefkästen collection_times:lastcheck benutzt - habe ich bei meinen Änderungen auch mit gesetzt.

Viele Grüße
wandsecacher

Moin!

lastcheck ist auch weit verbreitet.

Das Vorhaben unterstützte ich auch - sollte aber universell für andere Poi verwertbar sein.

Jan

Ein Frage von einem OSM-Anfänger: Hat man last_checked nicht auch schon implizit durch den Zeitstempel der letzter Änderung?

In Berlin habe ich auch ein paar Briefkästen aktualisiert :slight_smile:

Eventuell wurde ja nur die Position des BK korrigiert.

Also soll sich last_checked explizit auf das Attribut collection_times beziehen?

last_checked=* würde ich vorschlagen zu verwenden. Es muss ja nicht angegeben werden, ob die Öffnungs-, Leerungs-Zeit oder der Ort verändert wurde, das lässt sich aus der historie ablesen. Es sollte z.B. auch bei Gaststätten, Geschäften, POI’s gesetzt und geändert werden - Auch wenn sich nichts verändert hat ist ein neues Datum sinnvoll - und kann auch ausgewertet werden.

EDIT: *lastchecked= ** auf Grund der größeren Verwendung (last_checked sollte dann geändert werden).

Ich verweise auch nochmal auf http://unexpired.osm24.eu/#13/53.5665/10.0368 , das ist auch ein POI checker, dessen Autor aber das last_checked-Tag nicht mag[1]…

[1] http://www.openstreetmap.org/user/Dotevo/diary/23869

Moin !

ich bin dafür das lastcheck (so verwenden wir das hier) Lage und Leerungszeiten auswertet. Wenn ich die Leerungszeiten prüfe, dann ist der Standort geprüft.

Habe einmal eine Turbo-Abfrage erstellt für die mit lastcheck versehenen Postkästen im Lübecker Raum: http://overpass-turbo.eu/s/666

Eine weitere Abfrage soll die mit und ohne lastcheck versehenen Postkästen darstellen: http://overpass-turbo.eu/s/665 - leider ist es mir dort nicht gelungen den Style so anzupassen das die Kreise unterschiedlich dargestellt werden.

Was für die Sache aber auch noch in diesem Zusammenhang wichtig wäre ist eine Auswertung des zeitlichen Values wobei ich nicht weiß ob und wie das mit Overpass möglich ist. Aber die Zeit ist ja nicht der einzige Gesichtspunkt. Wenn die Objektversion 1 ist, dann wäre das Erstelldatum auch wichtig. Wenn dieses nämlich kleiner des Prüfzeitraums ist, dann würde der PK auch noch als geprüft gelten können.

Gruß Jan :slight_smile:

Bitschee!

Oder auch [url]http://overpass-turbo.eu/s/66i[/url] , wenn man direkt wissen will, wo man die nächsten Überprüfungen durchführen sollte. Die gelben Einfärbungen zeigen vorhandene lastcheck-Werte, die entweder sehr alt [Knoten [url]http://www.openstreetmap.org/node/295647607[/url] , letzte Überprüfung aus dem Jahre 1012 :)] sind oder nicht der Notation yyyy-mm-dd entsprechen. Der weiße Rand zeigt einen fehlenden zweiten Wert an (hier den Schlüssel operator).

Moin !

das sieht ja schon fast G… aus.

Was jetzt noch fehlt wäre eine Berücksichtigung der Tag-Varianten collection_times:lastcheck bzw. last_checked die hier genannt wurden und vielleicht eine Berücksichtigung des Operators als Variable (Deutsche Post…). Wird keiner genannt, dann mit berücksichtigen.

@user_5359 - kannst Du das noch erweitern?

Gruß Jan :slight_smile:

Damit Hamburg bunter wird (nicht politisch gemeint :slight_smile: ), nehme man die Abfrage http://overpass-turbo.eu/s/66w . Die alternative Schreibweise einfach mit Komma getrennt vor den geschweiften Klammer setzen, die folgende css-Anweisungen gelten dann für alle aufgeführte Schreibweisen. Für das Thema “Eintragen von Operator” muss die vorliegende Existenzprüfung reichen, eine Karte nach Operatoren wäre eine separate Karte.

Moin !

wenn man sich zum Beispiel

ansieht, dann wäre auch eine Verdichtung ein wichtiges Thema.

Gruß Jan :slight_smile:

Hallo Jan,

Das wäre eindeutig eine Entwicklungsaufgabe für Martin R. ( http://wiki.openstreetmap.org/wiki/User:Tyr )! Das hat mit den Thema nur indirekt zu schaffen.

Mit freundlichen Grüßen Georg V.

Sorry, verstehe ich nicht ganz. Wenn wir nach pk Die Augen offen halten dann können wir auch auf die fehlenden achten.

Gruss Jan

Hallo Jan,

im grafischen Umfeld redet man auch von einer Verdichtung (der Informationen), wenn man die grafischen Elemente (die Informationen) clustert. Also anstatt eine Gruppe (Cluster) von eng zusammenliegenden Elementen nur ein Element zeichnet und die Anzahl der Elemente dranhängt.

Du scheinst aber nicht von eine Verdichtung zu reden, sondern von einem “Lücken füllen”. Wenn man sich die Karte etwas genauer ansieht, sind da aber nicht mehr soviele Orte ohne Briefkasten vorhanden (ein Kandidat mit potentiell fehlenden Briefkasten wäre Seeth (http://www.openstreetmap.org/relation/1402989) oder auch Viöl (http://www.openstreetmap.org/relation/1406978))). Für einen Sammelaufruf für urlaubende Mapper in Schleswig-Holstein ist es rein jahreszeitlich zu spät, wir sollten das in Frühjahr 2015 wieder hervorholen.

Und dann auf keinen Fall vergessen: Operator, Sammelzeiten und Zeitstempel eintragen! (um mal auf das Thema zurückzukommen)

Mit freundlichen Grüßen Georg V.

Moin !

mir ist noch ein Gedanke gekommen, da amenity=post_box beim erstellen normalerweise kein lastckeck hat. Müßte es dann nicht einen Bot geben der bei Version 1 mit collection_times automatisch das Erstelldatum einträgt. Sonst werden selbst die “neusten” OSM-Briefkästen als veraltet dargestellt.

Es sei denn man kann diesen Sonderfall irgendwie mit der Overpass abfragen.

Gruß Jan :slight_smile: