CREATE TRIGGER trigger_polygon2
BEFORE INSERT OR UPDATE OR DELETE
ON planet_osm_polygon
FOR EACH ROW
EXECUTE PROCEDURE wno_check_postal_code();
wno_check_postal_code() ist dann eine PL/SQL-Funktion, die bei jeder Änderung eines Polygons automatisch die PLZ gegen eine interne Referenztabelle prüft.
-- Function: wno_check_postal_code()
-- DROP FUNCTION wno_check_postal_code(();
CREATE OR REPLACE FUNCTION wno_check_postal_code(()
RETURNS trigger AS
$BODY$
BEGIN
--
-- hier muß noch code rein
if (...) then
Raise notice "*** PLZ % ist falsch", postal_code;
end if;
--
return NEW;
END;
$BODY$
LANGUAGE plpgsql VOLATILE
COST 100;
Das eigentliche technische Problem ist - für mich - die Tatsache, dass der DIFF-Update mit osm2pgsql in einem cron-Job im Hintergrund läuft, die eigentliche Arbeit aber vom postgresql-daemon gemacht wird. Und nur der “sieht” das Problem. Es ist nicht einfach, die Info “PLZ FALSCH” zeitnah an jemanden weiterzuleiten. Da müsste man tief in den Logging-Mechanismus von Postgresql und Linux einsteigen, eine automatische Logfile-Analyse anstoßen und ggf eine Mail an einen “Betreuer” schicken. (*)
Selbst dann ist der Fehler schon im System und muß manuell durch einen ganz normalen OSM-Edit beseitigt werden.
Gruss
walter
*) Das geht natürlich, sonst müssten Administratoren ständig Logfiles lesen, aber ich hab das noch nie gemacht.
Wir hatten in anderen Threads hier im Forum ja schon über QS gesprochen. Das “Ergebnis” war ja im Wesentlichen: Geht leider nicht bzw. ist unpraktikabel. (Ich finde das etwas fatalistisch.)
Ein Forist hatte vorgeschlagen, für Extrakte Qualitätsangaben zu machen (Beispiel “Anzahl Geometrie-Fehler” u.ä.).
In der Tat mache ich das jetzt ähnlich. Ich bewerte bei mir lokal für jeden Tag (Geofabrik) die Grenzrelation in DE und prüfe auf gewisse Fehler. Nicht beim SQL-Update, sondern als paralleler Abfrageprozess. Leider habe ich eine Null-Toleranz-Anforderung und kann nur die Extrakte ohne Fehler nehmen. Das heißt dann, dass es maximal 1-2 Tage pro Woche ein verwertbares Ergebnis gibt.
EDIT: Ich überlege noch, wie ich das dann am besten mit minütlichen Planet-Updates mache.
dafür sind die SQL-Trigger optimal. Wenn es dir nichts ausmacht, den postgresql Serverlog zu lesen (kann ja auch ein grep sein), würde ich diesen Weg gehen.
Wie schon geschrieben, ist das eigentliche Problem nicht der Trigger sondern die automatische Benachrichtigung eines “Betreuers”. Alles andere ist easy - wenn man Trigger kennt
warte mal einen Tag ab, dann bin ich damit fertig.
Das ist ein im Prinzip lobenswerter Ansatz, ich würde aber nicht zu viel Aufwand reinstecken, da ich den “Erfolg” für fraglich halte.
Wer ist denn der “Betreuer”?
Der den way vor 3 Jahren angelegt hat?
Der die Relation vor 3 Tagen zerschossen hat?
… ?
Mir würde eine tabellarische Diff-Liste wie bei den Duplikaten in diesem Thread weiter oben reichen, entweder hier, in einem getrennten Thread oder von mir aus in einem Wiki.
Noch schöner wäre es als Markierung in OSMPC schon bei niederem Zoomlevel, das aber nur als Anregung (nicht als Arbeitsauftrag).
nö, ich meinte in erster Hinsicht (ohne Automatismus), denjenigen, der das dringend braucht - also gehrke selber Übrigens wohl auch die administrativen Grenzen.
wäre doch relativ einfach mit der Overpass machbar; nur kann ich die nicht, da ich alles mit PostgreSQL mache.
Jetzt hast du mir aber einen Floh ins Ohr gesetzt. Das Problem ist, daß meine Karte derzeit nur das anzeigt, was sie findet und nicht das, was sie nicht findet. Grübel, Grübel
Hmm. Erster Gedanke: Man könnte jedem Eintrag aus einer Referenzliste einen Centroid zuordnen und die PLZ dort entsprechend hervorgehoben zeichnen, wenn sich keine Relation für die PLZ findet. Ggf. noch eine Sonderbehandlung, wenn sich für den Centroid eine andere PLZ-Relation findet.
Schaun mer mal. Ich hab inzwischen schon eine Referenztabelle (8201 Entries sind wohl ok) und in 2 Minuten ist der Centroid auch drin.
danke für den Tip
Walter
Done:
#select country,"type","value",st_astext(pointonsurface) pointonsurface from boundaries;
country | type | value | pointonsurface
---------+------+-------+-------------------------------------
51477 | pc | 01067 | POINT(13.7104914983536 51.06011365)
51477 | pc | 01069 | POINT(13.7307897688335 51.04092775)
51477 | pc | 01097 | POINT(13.7370529719239 51.0670115)
51477 | pc | 01099 | POINT(13.8434834861318 51.0979804)
51477 | pc | 01108 | POINT(13.791659217969 51.15281005)
51477 | pc | 01109 | POINT(13.7523586370305 51.12140955)
51477 | pc | 01127 | POINT(13.7298386795764 51.0788104)
51477 | pc | 01129 | POINT(13.7306840494518 51.09772595)
51477 | pc | 01139 | POINT(13.6919074079352 51.07972135)
51477 | pc | 01156 | POINT(13.6181508329594 51.06591145)
...
51477 | pc | 99994 | POINT(10.6636364951025 51.24952705)
51477 | pc | 99996 | POINT(10.5945773695467 51.2885868)
51477 | pc | 99998 | POINT(10.5963676976598 51.2310608)
(8201 rows)
Country und type, damit ich an der Stelle flexibel bin.
Ich “arbeite” in meiner Software überall mit st_PointOnSurface(geom), weil der immer innerhalb der Fläche liegt (auch bei C-förmigen oder “löchrigen” Flächen) und dennoch ziemlich nahe am Zentrum liegt, wenn es möglich ist.
Und jeder Bürger benutzt stattdessen die Geo-Koordinaten der eigenen Haustür oder Terrasse, um sich per Amazon-Drohne seine Pakete zustellen zu lassen.
Nö, Amazon und Co werden natürlich die Hausnummer nehmen, in deren (nicht unserer) DB gucken wo die liegt, 3 Meter nach hinten fliegen und das Paket dort fallen lassen. Das kann noch richtig lustig werden. Eine PLZ brauchen die jedenfalls nicht.
Egal, wir schweifen ab und das sollte eh nur ein Scherz sein.
Gruss
walter
EDIT Patentanmeldung: Empfänger stellt einen 30x30cm großen “Landeplatz” mit einen fetten QR-Code in den Garten - feddich.
\set boundary 51477
drop table boundaries;
create table boundaries as (
select distinct :boundary::bigint as country,
'pc' as "type",
postal_code as "value",
pointonsurface
from planet_osm_polygon
where boundary in ('postal_code','administrative')
and length(postal_code)=5
and way && (select way from planet_osm_polygon where osm_id=-:boundary)
and st_contains((select way from planet_osm_polygon where osm_id=-:boundary),pointonsurface)
order by postal_code
);
alter table boundaries add unique(country,"type","value");
hab aber einige Felder in meiner DB, die so nicht im Standard-Profil von osm2pgsql drin sind.
Dieses Jahr wäre schon gut genug. Hatte ja vor einigen Woche bezweifelt, daß wir das 2013 hinkriegen.
Ich mache derzeit einige Updates der lokalen DB, bei denen ich die Diff-Verarbeitung lieber ausschalte. Heute ist der ziemlich spät damit fertig geworden.
Derzeit holt der Server noch die Diffs der Nacht nach; dann kann ich das checken.
In und um Kassel hat ein emilde zahlreiche Grenzen verändert. Dabei wurden fast alle dortigen PLZ-Relationen beschädigt.
Ich bin gerade dabei, das zu reparieren.
EDIT: Done. In einem Fall wurden sogar (von einem anderen User) zwei boundary-Wege übereinandergelegt - mit unterschiedlichem Start- und Endpunkt.
EDIT: Ich glaube, es gab jetzt schon über eine Woche keinen Tag ohne neue Grenzfehler mehr.
@gehrke: Daß bei uns Grenzen zerschossen wurden, kam doch immer vor. Es sind halt sensible Gebilde. Nur durch die große Zeitverzögerung beim OSM-Inspektor ist es nicht sofort aufgefallen. Mit einer eigenen Live-DB und passenden Auswertungen fällt das halt schneller auf.
Es ist genauso wie mit der angeblichen Zunahme von Katastrophen in gewissen Erdteilen oder im ehm. Ostblock - die gab es immer schon nur man hat nichts davon erfahren.
