Am Donnerstag 24 April 2008 schrieb Michael Bergbauer: > Oeffnungszeiten sind mitunter auch 'tagesaktuell'. Mir ists vor einiger > Zeit passiert, dass ich an nem Lokal in dem ich Essen wollte freundlich > aber sicher abgewiesen wurde: "Geschlossene Gesellschaft". > > Gut, das ist nun ein ganz anderes Problem, dass sich sicher nie > vermeiden lassen wird. > sowas wie geschlossene gesellschaften sind sicher nicht die regel. und wenn das in einem bestimmten lokal so sein sollte, kann man da ja drauf hinweisen.
> > erstmal braucht es so ein projekt, noch dazu mit einer definierten > > schnittstelle um das realisieren zu koennen. ausserdem wird dann > > garantiert eine hohe redundanz entstehen, wenn das ganze separat ist. > > Fuer Gaststaetten gabe es sowas zumindest teilweise schon (mir faellt da > gerade Kneipen-suche.com ein), in den GSoC-Projekten waren Vorschlaege > in dieser Richtung. Aber bitte wo sollen die Redundanzen entstehen? > eben, da alles in verschiedenen portalen gespeichert ist. kneipen-suche.com kann ich auch nicht offline nutzen. > Die Gruende, warum ich sowas im Rahmen eines anderen Projekts > sehen moechte sind vielfaeltig: > - die Pflege dieser Daten sollte von Leuten gemacht werden > koennen, die sich nicht erst in OSM und seine Datenstrukturen > einarbeiten wollen. das ist ein generelles problem. da muss man an den frontends bzw. editoren arbeiten, dass sich das aendert... > Diese Daten sind nicht 'offensichtlich' - wenn ich > heute einen Stadtteil, einen Ort gemapped habe und dort auch immer > wieder vorbei komme, dann habe ich ne Chance, neue Strassen, neue > Geschaefte zu bemerken. Aenderungen an den Oeffnungszeiten bemerke ich > aber nur, wenn ich ich das Lokal, den Laden, die Einrichtung gehe - wenn > ueberhaupt. vielleicht werden ja auch mal wirte oder stammgaeste auf das projekt aufmerksam. und die haben allen grund, die daten aktuell zu halten. ausserdem hat jeder node einen timestamp. wenn da ein eintrag jetzt aelter ist, darf man halt nur unter vorbehalt darauf setzen. > - Ich denke auch, dass die OSM-Datenstrukturen schlecht geeignet sind, > beispielsweise Oeffnungszeiten so zu erfassen, dass sie > maschinenlesbar sind. das ist bei vielen tags der fall. irgendwie gehts dann doch meistens. wenn man sowas aber gleich im hinblick auf die maschinenlesbarkeit entwickelt, dann sollte das kein problem sein. und die darstellung fuer den menschen ist sache z.B. der editoren. kein mensch sollte meiner meinung nach tags direkt editieren muessen, wenn er das nicht explizit so wuenscht. > Ich kann mir da bliebig viele mehr oder weniger > pathologische Sachen vorstellen, die aber sicherlich auch ihre > Anwendungsfaelle haben (z.B. in Verbindung mit Schulferien, > Feiertagen usw.). Hier bedarf es IMO anderer Datenstrukturen, und > auch Leute, die globale Daten wie z.B. Feiertage und Ferientermine > pflegen (wo koennten wir die in OSM beispielsweise einpflegen?). > zum beispiel vernkuepft mit einem polygon fuer das jeweilige land... > > fuer mich gehoeren solche allgemeinen infos in die osm-datenbank. > > Dann aber *bitte* auch Fahrplaninformationen. Dann kann man beim Routing > auch oeffentliche Verkehrsmittel mit einbeziehen. koennte man machen. muss man halt auch regelmaessig aktualisieren. wobei gerade das schon wieder eine hohe komplexitaet und sehr viele daten reinbringt. zumindest der mvv hier findet selber nicht immer die beste route; trotz vollstaendiger datenbank.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
