Mama, jemand hat die ganze Mittelrheinregion rosa angestrichen..!

Taunide · 2013-11-18 12:56:07

Gab es da irgendwo einen Wettbewerb: Wer den größten Landstrich in Level 10 einfärbt, hat gewonnen? Das schlägt noch die landuse=farmland-ganze-Verbandsgemeinde-taggen-Landschaftsmaler.

http://www.openstreetmap.org/browse/way/246602883

Und dann noch die Chuzpe haben als note reinzuschreiben "Genauen Gebietsverlauf noch finden"

Nop · 2013-11-18 13:09:59

Das dürfte eine etwas freizügige Interpretation der Tags monument und attraction sein, außer das Mittelrheintal wurde mittlerweile überdacht. Eher angemessen wäre wohl protected_area.

Aber sehen wir's positiv: Jetzt ist die chinesische Mauer nicht mehr das einzige Monument, das aus dem Weltraum mit bloßem Auge zu erkennen ist. :-)

bye, Nop

rayquaza · 2013-11-18 13:15:44

Nop wrote:

Das dürfte eine etwas freizügige Interpretation der Tags monument und attraction sein, außer das Mittelrheintal wurde mittlerweile überdacht. Eher angemessen wäre wohl protected_area.

Und das Wikipedia-Tag ist auch gut gewählt

Nadjita · 2013-11-18 13:20:10

Als gebürtige Darmstädterin kann ich bezeugen, dass das nicht die Grube Messel ist. Ich bin entsetzt ob dieser Ignoranz

GeorgFausB · 2013-11-18 13:20:26

Moin,

also wirklich falsch ist doch da nur das historic=monument und den irreführenden wikipedia-Link ...
Das tourism=attraction entspricht doch nun wirklich der Wahrheit - der man nunmal ins Auge sehen muss!
Und mit dem layer=-2 hat er/sie/es sich doch wirklich Mühe gegeben, die Auswirkung abzumildern ...

Gruß
Georg

cepesko · 2013-11-18 13:23:57

HHHiiiilfe, das war ich.....:o

Hatte bei der Betrachtung der historischen Karte gesehen, dass die Grube Messel aufgeführt als UNESCO-Erbe aufgetaucht, aber das Obere Mittelrheintal nicht trotz historischer Bedeutung. In Anlehnung an das Tagging von Messel habe ich wohl ein Tag (area?) zuviel übernommen.....
Cepesko

PS: Bin noch auf der Arbeit, kann jemand schneller das Problem für mich lösen?

Netzwolf · 2013-11-18 14:04:30

Nahmd,

cepesko wrote:

Hatte bei der Betrachtung der historischen Karte gesehen, dass die Grube Messel aufgeführt als UNESCO-Erbe aufgetaucht, aber das Obere Mittelrheintal nicht trotz historischer Bedeutung. In Anlehnung an das Tagging von Messel habe ich wohl ein Tag (area?) zuviel übernommen.....
Cepesko
PS: Bin noch auf der Arbeit, kann jemand schneller das Problem für mich lösen?

[×] done

Protected area möge noch jemand nachtragen, der sich damit auskennt.

Gruß Wolf

cepesko · 2013-11-18 16:22:14

Danke, Wolf, für die schnelle Korrektur meines Fehlers.

Cepesko

@NOP:
War in Gedanken der Begrifflichkeit der "National Monuments" in USA. Info: Dort ist ein "monument" oft ein großes Gebiet (monument), z.B. mit 34.000 qkm so groß wie ganz NRW.

@Nadjita/Georg:
Habe beide Orte besucht: Das Rheintal ist höchst attraktiv, z.B. Bacharach, Kaub, etc. Aber bei der Grube Messel müssten wir tourist=attraction ganz schnell entfernen. Wenn du da reinläufst, siehst du fast nix, außer Bitumen und der ehem. Müllumladestation, den gelagerten YTONG-Steinen am Horizont und viel Zaun. Enttäuschend. Vielleicht wäre ein Täg attraction=horror besser.

PS: Hatte jemand Dresden UNESCO-mäßig (um-)getaggt? disused/abandonned/depreciated/protected=no/punished=yes

berndw · 2013-11-27 18:23:25

OSMand zeigt diese Region mittlerweile auch in zartrosa

Last edited by berndw (2013-11-27 18:26:06)

chris66 · 2013-11-28 09:16:15

Ja, ist halt immer Glücksache, solange wir kein "stable-version" unserer Daten haben.

Gehrke · 2013-11-28 10:05:34

chris66 wrote:

Ja, ist halt immer Glücksache, solange wir kein "stable-version" unserer Daten haben.

"stable-version"??? Gab es mal einen "stable moment"?

Bitte nicht falsch verstehen. Aber für Unternehmen ist gerade das vielleicht der Haken bei OSM.
Und ich bin gerne bereit, an Überlegungen und Vorschlägen hierzu beizutragen (ohne dass ich jetzt schon Patentrezepte hätte...).

chris66 · 2013-11-28 10:45:00

Gehrke wrote:

"stable-version"??? Gab es mal einen "stable moment"?

Vermutlich nicht. Mal ist hier was kaputt, mal dort.
Patentrezept hab ich auch nicht. Folgenden Gedanken hatte ich mal:
In der letzten Woche jeden Monats sind nur noch Reparaturen an den Daten erlaubt. Anfänger etc. sind dann nicht zugelassen, so dass man Ende des Monats halbwegs saubere Daten hat.

Gehrke · 2013-11-28 11:13:04

chris66 wrote:

Gehrke wrote:
"stable-version"??? Gab es mal einen "stable moment"?
Vermutlich nicht. Mal ist hier was kaputt, mal dort.
Patentrezept hab ich auch nicht. Folgenden Gedanken hatte ich mal:
In der letzten Woche jeden Monats sind nur noch Reparaturen an den Daten erlaubt. Anfänger etc. sind dann nicht zugelassen, so dass man Ende des Monats halbwegs saubere Daten hat.

Ich bin Informatiker. Das klingt für mich nach einer Art von "Code-Freeze"-Phase vor einem Release. Aber das passt vielleicht nicht so super zur dynamischen und "agilen" Ausrichtung von OSM.
Andere Begriffe, die mir zum Thema noch einfallen, sind: Continuous Integration mit automatisierten Tests (auf Server-Seite!) und Continuous Delivery. Derzeit haben wir quasi schon Continuous Delivery nur leider ohne die eigentlich obligatorischen Tests.

Last edited by Gehrke (2013-11-28 12:22:28)

Nop · 2013-11-28 13:47:34

Das ist genau das Problem bei einer professionellen Nutzung, für das es derzeit keine Lösung gibt.
- keine Zielrichtung, jeder herausgegriffene Stand kann zufällig gut oder auch katastrophal schlecht sein
- keine Testmethode um die Qualität eines Standes zu bewerten

bye, Nop

Oli-Wan · 2013-11-28 14:25:37

chris66 wrote:

Patentrezept hab ich auch nicht. Folgenden Gedanken hatte ich mal:
In der letzten Woche jeden Monats sind nur noch Reparaturen an den Daten erlaubt. Anfänger etc. sind dann nicht zugelassen, so dass man Ende des Monats halbwegs saubere Daten hat.

Ein alternativer Weg wäre, die interessierenden Daten zu extrahieren (Entkopplung von der Live-Datenbank), diesen Extrakt zu korrigieren und das Ergebnis verfügbar zu machen. Nachteil: der Aufwand für die Korrekturen kommt nicht der eigentlichen Datenbank zugute. Vorteil: Eben weil man nicht in der Live-Datenbank herumfuchtelt, kann man auch relativ grobmotorische automatische Korrekturen laufen lassen, die in OSM selbst nicht akzeptabel wären, etwa Objekte mit strukturellen Defekten schlichtweg löschen.
Für Mapper wäre es natürlich höchst unattraktiv, sich z.B. monatlich am Aufräumen eines Länderextraktes zu beteiligen, und weitaus sinnvoller, die Fehler stattdessen einmalig in der Datenbank zu beheben, auch wenn man so nie völlige Fehlerfreiheit - ohnehin nur bezüglich definierter Fehlerklassen - an einem Stichtag erreicht. Bleibt noch eine automatisierte "Veredelung", die natürlich auch nur eine (eher kleine) Teilmenge aller Fehler beheben oder zumindest symptomatisch behandeln kann. Daß bisher niemand so etwas anbietet, mag einen Hinweis auf das Ausmaß der Nachfrage geben. Zumal die höchst variablen Anforderungen verschiedener Nutzer schon mit der Nutzung verschiedener, unterschiedlich fehlertoleranter Renderer und sonstiger Programme anfangen.

Nop wrote:

Das ist genau das Problem bei einer professionellen Nutzung, für das es derzeit keine Lösung gibt.
- keine Zielrichtung, jeder herausgegriffene Stand kann zufällig gut oder auch katastrophal schlecht sein
- keine Testmethode um die Qualität eines Standes zu bewerten

Eigentlich müßte nur die Geofabrik mit jeder Aktualisierung des OSM Inspector die gefundenen Fehler zählen. Am besten gleich länderweise und die Ergebnisse auf der Download-Seite für die Extrakte anzeigen; und schon könnte ein Anwender entscheiden, einen aktuellen Extrakt nicht zu verwenden, wenn sich etwa die Anzahl der Routingfehler gegenüber dem Vortag verdoppelt hat. (Der OSM Inspector findet natürlich - wie jedes andere Tool - nur eine Teilmenge aller Fehler, aber als relativer Indikator taugt die gefundene Anzahl allemal.)

seichter · 2013-11-28 17:04:00

Ich bin der Meinung, dass wir da ein grundsätzliches Problem anschneiden, das es verdient hätte, aus dem rosa Anstrich herausgelöst zu werden (sprich ein eigener Thread).

Eine Schwäche des Projektes OSM ist es, dass wir ein continuous delivery ohne ernsthafte Qualitätssicherung haben. Die Revert-Aktionen nach Meteoreinschlag in München, beleidigten Förstern, iD-Quadraturen etc. passieren ja erst, nachdem das Kind schon in den Brunnen gefallen ist.

Mapping ist aber so verschieden von SW-Entwicklung oder Wikipedia, dass die dortigen Mechanismen nur äußerst eingeschränkt übernommen werden können. Aktualität ist eine Kerneigenschaft, die mMn nur durch die Möglichkeit zum sofortigen Eintragen von Informationen erreichbar ist. Auch die Motivation sänke rapide, wenn das nicht mehr sofort möglich wäre.

Andererseits ist bereits eine so wertvolle Informationsbasis aufgebaut, dass man diese nicht schutzlos jeder gewollten oder ungewollten Aktion preisgeben sollte. Kommerzielle Nutzbarkeit ist sicher nicht das Hauptanliegen von OSM, aber nur für die Blumenvase ist die ganze Arbeit zu schade.

Bei "stable version" kommt mir der Gedanke, in der Richtung sich auch etwas für OSM zu überlegen.
Ich könnte mir eine "live version" vorstellen, in die alles wie bisher eingetragen wird. Aus der werden die neuen Einträge aber erst nach grober Plausibilitätsprüfung (siehe iD-Unfall-Diskussion), abhängig vom Umfang und nach einer Wartefrist automatisch in die stable übernommen. In dieser Wartefrist kann jeder gegen einen Neueintrag Einspruch erheben und der wird dann zunächst gegen Übernahme gesperrt. Wie und durch wen dieser Konflikt aufgelöst würde, müsste noch festgelegt werden.
Auch gegen Trolle könnte in dieser Karenzzeit viel effektiver vorgegengen werden.

Das ist ebenfalls kein Patentrezept und dass dieses Vorgehen noch viele andere Fragen aufwirft, dürfte klar sein: Welche Version soll als Standardkarte angezeigt werden, wie erkenne ich, ob ein Eintrag noch "live" oder schon "stable" ist, was passiert mit Änderungen, die auf verworfenen "live"-Änderungen aufbauen, usw.

Ich bin aber der Meinung, dass OSM inzwischen so weit gediehen ist, dass es sich lohnt, sich auch über solche Probleme mal Gedanken zu machen.

S-Man42 · 2013-11-28 17:09:57

kurz und bündig:
++++1

Wegabschneider · 2013-11-29 11:23:37

Eine stabile Version, die mehr Zuverlässigkeit bietet als die live. Solch einen Gedanken hatte ich ebenfalls schon. Ich habe, wie wohl andere auch, schon die Datenqualität angesprochen. Ich kann so eine Zweiteilung nur befürworten.

Nop · 2013-11-29 12:39:01

seichter wrote:

Bei "stable version" kommt mir der Gedanke, in der Richtung sich auch etwas für OSM zu überlegen.
Ich könnte mir eine "live version" vorstellen, in die alles wie bisher eingetragen wird. Aus der werden die neuen Einträge aber erst nach grober Plausibilitätsprüfung (siehe iD-Unfall-Diskussion), abhängig vom Umfang und nach einer Wartefrist automatisch in die stable übernommen. In dieser Wartefrist kann jeder gegen einen Neueintrag Einspruch erheben und der wird dann zunächst gegen Übernahme gesperrt. Wie und durch wen dieser Konflikt aufgelöst würde, müsste noch festgelegt werden.
Auch gegen Trolle könnte in dieser Karenzzeit viel effektiver vorgegengen werden.

So ein Vorgehen wäre theoretisch wünschenswert. Das Konzept kann aber nicht funktionieren, da die Änderungen nicht einfach zeitverzögert übernommen werden können, weil alles miteinander verflochten ist. Das ist schon bei einem Revert ein Problem, daß er schnell erfolgen muß bevor jemand anders etwas geändert hat. Oder das war ein großes Problem beim Redaction bot gezielt Informationen zu entfernen.

Wenn die Übernahme abhnängig vom Umfang oder mit unterschiedlichen Wartezeiten erfolgt, können sich logisch zusammengehörende Edits überholen und es entstehen dadurch korrupte Zustände. Wenn einzelne Änderungen nicht in die stable wandern ist alles in Frage gestellt was räumlich oder logisch danach weiter editiert wird. Um das zu reparieren wären direkte, abweichende Edits auf der stable nötig, die dann aber den Unterschied zur live noch größer machen und die Diskrepanz breitet sich immer weiter aus.

Die andere Frage ist natürlich wer die Prüfung für alle Änderungen vornehmen soll. Damit baust Du einen gewaltigen Druck auf, was abzuarbeiten ist.

Ich denke der einzige technisch machbare Ansatz wäre es, eine Plausibilitätsprüfung, Begrenzungen für Anfänger und verwarnte Accounts und/oder einen Zurückweisungs- oder Freigabemechanismus in die API einzubauen, so daß verdächtige Dinge nicht direkt in der Datenbank landen. Aber auch hier hat man das Problem daß die Entscheidung sehr schnell fallen muß bevor Konflikte entstehen.

bye, Nop

S-Man42 · 2013-11-29 12:51:26

Ohne jetzt groß darüber nachgedacht zu haben: Aber ist es vielleicht sinnvoll, Wartezeiten für endgültige Übernahmen zu definieren?

Ich stelle mir das grob so vor: Änderungen werden nur in einer temporären DB gemacht. Jeder arbeitet auf diesem Mirror, jeder ändert und checkt. Aber jede Änderung wird - sagen wir - eine Woche nicht in den Hauptzweig geführt. Ist also Blödsinn passiert, braucht man erstmal nur in der temporären DB zu fixen und man fasst den Hauptbranch nicht an. Aber dadurch dass alle auf dem Mirror arbeiten, dürften keinerlei Konflikte oder so auf dem Mainbranch zustande kommen, denke ich.

Hmm, mir fällt grad ein, was passiert, wenn ein Revert genau über die Wochengrenze hinweg passiert... Dann kommts zu komischen Ergebnissen.. Hm...

hurdygurdyman · 2013-11-29 13:53:01

S-Man42 wrote:

Ohne jetzt groß darüber nachgedacht zu haben: Aber ist es vielleicht sinnvoll, Wartezeiten für endgültige Übernahmen zu definieren?
Ich stelle mir das grob so vor: Änderungen werden nur in einer temporären DB gemacht. Jeder arbeitet auf diesem Mirror, jeder ändert und checkt. Aber jede Änderung wird - sagen wir - eine Woche nicht in den Hauptzweig geführt. Ist also Blödsinn passiert, braucht man erstmal nur in der temporären DB zu fixen und man fasst den Hauptbranch nicht an. Aber dadurch dass alle auf dem Mirror arbeiten, dürften keinerlei Konflikte oder so auf dem Mainbranch zustande kommen, denke ich.
Hmm, mir fällt grad ein, was passiert, wenn ein Revert genau über die Wochengrenze hinweg passiert... Dann kommts zu komischen Ergebnissen.. Hm...

Und wenn einer während der Wartezeit am selben herumdreht, gibt es den Konflikt aus verschiedenen Bearbeitungen, von denen kein Admin wissen kann, welcher richtiger ist

S-Man42 · 2013-11-29 14:04:51

Gut, aber das ist ja aktuell auch nicht anders. Ich sage ja nicht, dass DAS dadurch automatisch besser wird: Vielmehr dachte ich erstmal nur an die Fälle, wo es einfach offensichtlichen Vandalismus, großflächige Löschugnen, etc. gab. Die fängt man so ab, ohne dass sie in der Map bzw. dem eigentlichen Datensatz landen. Klar, was ich meine?

Last edited by S-Man42 (2013-11-29 14:05:01)

JohnDoe23 · 2013-11-29 14:33:04

S-Man42 wrote:

Gut, aber das ist ja aktuell auch nicht anders. Ich sage ja nicht, dass DAS dadurch automatisch besser wird: Vielmehr dachte ich erstmal nur an die Fälle, wo es einfach offensichtlichen Vandalismus, großflächige Löschugnen, etc. gab. Die fängt man so ab, ohne dass sie in der Map bzw. dem eigentlichen Datensatz landen. Klar, was ich meine?

Aber aktuell lädt man die Daten auch schnell wieder hoch, da vergeht weniger Zeit, in der jemand anderes das selbe Objekt editieren könnte und somit zerlegt. Geänderte Objekte zu sperren, bis sie von jmd. anders bestätigt wurden dürfte wohl auch nicht wirklich praktikabel sein (z.B. bei Grenzrelationen, ...)

Ich denke dass solche hypothetischen Probleme erst gelöst werden, sobald sie wirklich drängend werden. Bis jetzt gab es soweit ich weiß ja noch keine wirkliche böswillige Manipulationen der Daten, außer ein paar Kahlschlägen, oder?

Was sich mir nicht ganz erschließt, warum der API-Zugriff offenbar unbeschränkt ist, da kann man einfach mal so 30.000 Nodes löschen: http://www.openstreetmap.org/browse/cha … ay_page=12 oder 50.000 leere Nodes anlegen: www.openstreetmap.org/browse/changeset/19122607 Da könnte man sicherlich ein Limit einführen + Ausnahmegenehmigungen für Massenimporte durch die DWG oder andere (demokratisch bestimmte?) Entscheidungsinstanzen.

Aber wie gesagt, solange sich solche Sachen in Grenzen halten, wird wohl nicht viel passieren.

Gehrke · 2013-11-29 14:49:41

JohnDoe23 wrote:

Geänderte Objekte zu sperren, bis sie von jmd. anders bestätigt wurden dürfte wohl auch nicht wirklich praktikabel sein (z.B. bei Grenzrelationen, ...)

Denke auch, dass das nicht praktikabel ist. Aber warum gibt es beim Upload nicht einfach einen Fehler, wenn z.B. eine Grenzrelation nicht (mehr) geschlossen ist?

Netzwolf · 2013-11-29 15:16:03

Moins,

bevor der Backofen explodiert: wie wäre es, erst einmal *ganz* kleine Brötchen zu backen.

Ein Beispiel: man könnte die geometrische Wohlgeformtheit von type=multipolygon-Relationen auf dem Server durchsetzen. Das sollte technisch kein Hexenwerk sein (wobei ich die durch die Prüfung erzeugte Serverlast nicht beurteilen kann), und würde u.a. das Problem defekter Admin-Relationen und das “und täglich grüßt das Postleitzahlenfresstier” verkleinern.

Kostet aber.

Denn ein Editor sollte vor dem Hochladen den Test des DB-Servers vorwegnehmen, um Ablehnungen zu vermeiden. Wenig Probleme machen Split eines Weges (wenn das neue Teilstücke in die gleichen Rels kommt wie das Basisstück), Join mit einem Way exakt gleicher Relzugehörigkeit und Verfeinerung eines Ways durch Einfügen innerer Punkte: das alles kann ein wohlgeformtes MP nicht beschädigen.

Sobald aber ein Wegstück entfernt oder eines ergänzt oder verkürzt oder verlängert wird, muss das MP nachgerechnet werden. Das muss zum einen implementiert sein, zum anderen muss der Editor dazu alle (viele+lange) Wegstücke des MP laden.

Während der Arbeit an einem MP ist das MP (natürlich) nicht wohlgeformt. Was bei JOSM kein Problem ist (ich lade erst nach vollständiger Bearbeitung hoch, wenn das MP wieder ok ist), schränkt einen Editor wie iD, der Änderungen sofort hochlädt, ein: Wege, die Bestandteil eines MP sind, kann man weder löschen noch verkürzen, und aus einem Verlängern muss der Editor ein Ansetzen einer neuen Linie mit gleichen Attributen machen.

Schon diesen simplen Schritt in Richtung einer konsistenteren DB (der kleinste, der mir eingefallen ist) bezahlt man teuer: mit Entwicklungsarbeit und mit Einschränkungen bei der Editierbarkeit.

Will man den Preis der Müllvorbeugung nicht bezahlen, so wird weiterhin Müll hochgeladen und man bezahlt für die Müllentsorgung. Oder hofft, dass es genügend freiwillige Müllwerker gibt.

Gruß Wolf

Announcement

#1 2013-11-18 12:56:07

Mama, jemand hat die ganze Mittelrheinregion rosa angestrichen..!

#2 2013-11-18 13:09:59

Re: Mama, jemand hat die ganze Mittelrheinregion rosa angestrichen..!

#3 2013-11-18 13:15:44

Re: Mama, jemand hat die ganze Mittelrheinregion rosa angestrichen..!

#4 2013-11-18 13:20:10

Re: Mama, jemand hat die ganze Mittelrheinregion rosa angestrichen..!

#5 2013-11-18 13:20:26

Re: Mama, jemand hat die ganze Mittelrheinregion rosa angestrichen..!

#6 2013-11-18 13:23:57

Re: Mama, jemand hat die ganze Mittelrheinregion rosa angestrichen..!

#7 2013-11-18 14:04:30

Re: Mama, jemand hat die ganze Mittelrheinregion rosa angestrichen..!

#8 2013-11-18 16:22:14

Re: Mama, jemand hat die ganze Mittelrheinregion rosa angestrichen..!

#9 2013-11-27 18:23:25

Re: Mama, jemand hat die ganze Mittelrheinregion rosa angestrichen..!

#10 2013-11-28 09:16:15

Re: Mama, jemand hat die ganze Mittelrheinregion rosa angestrichen..!

#11 2013-11-28 10:05:34

Re: Mama, jemand hat die ganze Mittelrheinregion rosa angestrichen..!

#12 2013-11-28 10:45:00

Re: Mama, jemand hat die ganze Mittelrheinregion rosa angestrichen..!

#13 2013-11-28 11:13:04

Re: Mama, jemand hat die ganze Mittelrheinregion rosa angestrichen..!

#14 2013-11-28 13:47:34

Re: Mama, jemand hat die ganze Mittelrheinregion rosa angestrichen..!

#15 2013-11-28 14:25:37

Re: Mama, jemand hat die ganze Mittelrheinregion rosa angestrichen..!

#16 2013-11-28 17:04:00

Re: Mama, jemand hat die ganze Mittelrheinregion rosa angestrichen..!

#17 2013-11-28 17:09:57

Re: Mama, jemand hat die ganze Mittelrheinregion rosa angestrichen..!

#18 2013-11-29 11:23:37

Re: Mama, jemand hat die ganze Mittelrheinregion rosa angestrichen..!

#19 2013-11-29 12:39:01

Re: Mama, jemand hat die ganze Mittelrheinregion rosa angestrichen..!

#20 2013-11-29 12:51:26

Re: Mama, jemand hat die ganze Mittelrheinregion rosa angestrichen..!

#21 2013-11-29 13:53:01

Re: Mama, jemand hat die ganze Mittelrheinregion rosa angestrichen..!

#22 2013-11-29 14:04:51

Re: Mama, jemand hat die ganze Mittelrheinregion rosa angestrichen..!

#23 2013-11-29 14:33:04

Re: Mama, jemand hat die ganze Mittelrheinregion rosa angestrichen..!

#24 2013-11-29 14:49:41

Re: Mama, jemand hat die ganze Mittelrheinregion rosa angestrichen..!

#25 2013-11-29 15:16:03

Re: Mama, jemand hat die ganze Mittelrheinregion rosa angestrichen..!

Board footer