Re: [Talk-de] Postkästen-Leerungszeiten-Kontrolle
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 15.07.2011 20:07, schrieb Wolfgang: Am Freitag, 15. Juli 2011 15:11:28 schrieb fly: Am 15.07.2011 13:58, schrieb Henning Scholland: Der Ansatz, das Objekt mit zusätzlichen Tags komplexer zu machen ist kontraproduktiv. - -1 (siehe unten) Was ihr möchtet sind aktuelle Infos. Die erhält man, wenn viele Mapper sich daran beteiligen und Veränderungen eintragen. Das ist klar, ist aber unabhängig davon. Die Editoren sind bereits kompliziert und werden jeden Tag komplizierter. Da spielt ein einzelnes, verständliches tag keine Rolle mehr. Wer Angst hat, etwas kaputt zu machen, wird sich so sowieso nicht beteiligen. Gerade der Ansatz foo=bar foo:last_check=20110716 (o.ä.) kann doch wunderbar vom Editor ausgewertet werden. (Sofern das Datumsformat eindeutig ist.) Wenn die Tags paarweise auftreten, kann der Editor die *:last_check-Tags unterdrücken und als Zusatzinformation am zugehörigen Haupt-Tag anzeigen. Beim Hinzufügen oder Ändern eines Wertes könnte der Editor das Datum automatisch ergänzen. Zusätzlich könnte der Editor die Tabelle der vorhandenen Tags um Checkboxen ergänzen, bei denen der Anwender einfach ein Häkchen setzen kann, daß der Wert noch aktuell ist. (Optional kann man auch ein älteres Datum eintragen, falls die Daten nicht am gleichen Tag gepflegt werden.) Also könnte man das für den Anwender sehr einfach unübersichtlich machen. Eine tolle Sache um euer Ziel zu erreichen wäre bspw. ein Routenplaner, der entlang der Route ein paar Punkte vorschlägt, die man überprüfen kann und man dafür Punkte für einen Highscore erhält. Auch für einen solchen Routenplaner wäre die vorgeschlagene Kennzeichnung hilfreich zur Auswahl der zu prüfenden Objekte oder zur Score-Festlegung. Ich bleibe dabei, dass ich einen solchen tag für sinnvoll halte. Niemand wird gezwungen, sich daran zu beteiligen. +1 Viele Grüße Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk4hMT4ACgkQnMz9fgzDSqd3iwCfSaEQuowaK042eyIoUpAzD3nc SbAAn0Sa7zn2IkbOisDXnQjiHXoajTzi =Gxic -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Postkästen-Leerungszeiten-Kontrolle
Am 15.07.2011 20:07, schrieb Wolfgang: Ich bleibe dabei, dass ich einen solchen tag für sinnvoll halte. Niemand wird gezwungen, sich daran zu beteiligen. Wenn in A-Stadt die Briefkästen regelmäßig mit einem checked-Tag versehen werden und in B-Stadt ein Mapper ebenfalls regelmäßig kontrolliert, aber das Tag nicht setzt, dann ergibt sich für den Nutzer ein völlig inkonsistentes Bild. Auf der German Postbox Map steht dann bei den Briefkästen in A-Stadt Stand 15.07.2011, bei denen in B-Stadt Stand=datum letzte version des nodes, was u.U. Jahre zurückliegt. Natürlich wird der Nutzer die Information der Kästen in B-Stadt skeptisch bewerten oder gar gleich als veraltet betrachten. Ein solches Tag gibt daher nur Sinn, wenn es flächendeckend und systematisch gesetzt wird, und das geht nur, wenn sich alle beteiligen. Da dies weder machbar noch wünschenswert ist, ist das checked-Tag kontraproduktiv, denn es verschlechtert die subjektive Qualität von Objekten, deren Daten aktuell und korrekt sind, die aber nicht mit einem solchen Flag versehen sind. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Postkästen-Leerungszeiten-Kontrolle
Am 16.07.2011 08:35, schrieb Bodo Meissner: [...] Beim Hinzufügen oder Ändern eines Wertes könnte der Editor das Datum automatisch ergänzen. Bitte nicht. Wenn ich einen Rechtschreibfehler finde (z.b. highway=resedential) oder einfach nur ohne Wissen über die tatsächlichen Fakten das Format der opening_hours korrigiere, weil wieder jemand deutsche Wochentage benutzt hat, dann ist das eben kein last_checked, sondern einfach eine Syntaxkorrektur. Wenn der Editor das automatisch als überprüft setzt, haben wir nichts gewonnen gegenüber den Changeset-Informationen zum Änderungsdatum. Zusätzlich könnte der Editor die Tabelle der vorhandenen Tags um Checkboxen ergänzen, bei denen der Anwender einfach ein Häkchen setzen kann, daß der Wert noch aktuell ist. (Optional kann man auch ein älteres Datum eintragen, falls die Daten nicht am gleichen Tag gepflegt werden.) Also könnte man das für den Anwender sehr einfach unübersichtlich machen. +1 Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Postkästen-Leerungszeiten-Kontrolle
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 16.07.2011 09:18, schrieb Peter Wendorff: Am 16.07.2011 08:35, schrieb Bodo Meissner: [...] Beim Hinzufügen oder Ändern eines Wertes könnte der Editor das Datum automatisch ergänzen. Bitte nicht. Wenn ich einen Rechtschreibfehler finde (z.b. highway=resedential) oder einfach nur ohne Wissen über die tatsächlichen Fakten das Format der opening_hours korrigiere, weil wieder jemand deutsche Wochentage benutzt hat, dann ist das eben kein last_checked, sondern einfach eine Syntaxkorrektur. Stimmt. Mein Vorschlag ist sicher noch nicht ausreichend durchdacht. Es ist nicht sinnvoll, wenn beim manuellen Eintragen von Schlüssel und Wert automatisch zusätzliche Tags generiert werden. Hintergrund meiner Idee war es, dem weniger versierten Mapper die Arbeit möglichst einfach zu machen. Wenn der zu jedem Wert immer noch ein Häkchen setzen muß, um das Datum der Datenerhebung einzutragen, macht es mehr Arbeit. Dieser Mapper wird sich vielleicht weniger um das Korrigieren von Syntaxfehlern kümmern. Vielleicht braucht man einfach eine Konfiguration, um zu wählen, ob der Editor standardmäßig das Datum ändern soll oder nicht. Vielleicht wäre eine automatische Eintragung des Aktualitätsdatums sinnvoll, wenn man mit Presets bzw. einem speziellen Öffnungszeiten-Editor o.ä. arbeitet. Wenn der Editor das automatisch als überprüft setzt, haben wir nichts gewonnen gegenüber den Changeset-Informationen zum Änderungsdatum. Nur eine leichtere Auswertemöglichkeit, wann welches Tag geändert wurde. Viele Grüße Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk4hQKAACgkQnMz9fgzDSqe6rACePg1D3qBqKpDDQp8RJhr0qJMT SfkAn0T6yAehxl5BchFx2J+XedgzruwC =ndW1 -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wanderzeichen mit Relationen verbinden
Hallo zusammen, ich bin gerade dabei verschiedene Wanderwege zu erfassen. Dabei habe ich Probleme Wanderzeichensymbole mit den Relationen zu verknüpfen. Das Wanderzeichen Weinwanderweg.svg habe ich schon hochgeladen. Auch auf die Wiki-Seite Wanderzeichen habe ich das Symbol unter Weintraube eingepflegt. Nur weiß ich nicht wie man bei der Relation dieses angibt. Ich habe es mit dem Tag wiki:symbol probiert, aber keine Auswirkungen feststellen können. Leider gibt es zu diesem Tag auch noch keine Beschreibung. hike39 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Insel im Meer
Am 15. Juli 2011 14:26 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.com: Für Inselgruppen fehlt hingegen noch ein Tagging-vorschlag (AFAIK), d.h. da könnte man helfen. Vorschlag für den Key: natural (das sehe ich als Hauptkey für geografische Features, s. dort z.B. was es schon gibt: Gipfel, Quelle, Höhleneingang, Strand, Bucht, etc.). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Postkästen-Leerungszeiten-Kontrolle
Am 15.07.2011 20:07, schrieb Wolfgang: Dass sich ständig etwas ändert und keine Datensammlung ganz aktuell sein kann, ist klar. Damit bleibt es für den Anwender gleich - immer zu 50% Wahrscheinlichkeit richtig, egal wie viel Aufwand ich reinstecke... Da hilft es dann auch nicht weiter wenn dafür bei 100 anderen Objekte die Werte richtig sind. Der Ansatz, das Objekt mit zusätzlichen Tags komplexer zu machen ist kontraproduktiv. Was ihr möchtet sind aktuelle Infos. Die erhält man, wenn viele Mapper sich daran beteiligen und Veränderungen eintragen. -1 Wenn der Mapper sieht, dass der Laden mit Öffnungszeiten fertig ist, kümmert er sich nicht mehr um Details. Alles andere wäre Zufall. Bei den Läden die mir wichtig sind jedenfalls ehr als bei welchen bei denen einfach nur das Mindesthalbarkeitsdatum abgelaufen ist... Diese Mapper gewinnt man, wenn diese die Infos einfach eintragen können. Wenn diese Leute im Editor dann zig Tags vorfinden, deren Bedeutung sie nicht kennen, lassen sie das Editieren aus Angst etwas kaputt zu machen eher sein. Die Editoren sind bereits kompliziert und werden jeden Tag komplizierter. Da spielt ein einzelnes, verständliches tag keine Rolle mehr. Wer Angst hat, etwas kaputt zu machen, wird sich so sowieso nicht beteiligen. Wie der Thread hier zeigt gibt es durchaus Missverständlichkeitspotential (z.B. gilt das Datum für das ganze Objekt oder nur für einen Tag) Eine tolle Sache um euer Ziel zu erreichen wäre bspw. ein Routenplaner, der entlang der Route ein paar Punkte vorschlägt, die man überprüfen kann und man dafür Punkte für einen Highscore erhält. Dann wird ein Laden 100x überprüft, und andere gar nicht. Die Motivation Läden zu überprüfen die einem eigentlich nicht interessieren wird so oder so gering bleiben Alles andere bläht nur die History auf. Das kann sie ab. Die History vielleicht schon, die Auswertung bremst sie aus Ich kenne Ecken, wo die Läden fast monatlich wechseln nur wann ist nicht abzusehen. Das kann Morgen oder in fünf Tagen bzw gestern sein. Andere Stellen verändern sich über Jahre nicht. Dann ist es doch gut, wenn diese Ecken ab und zu mal gecheckt werden. Mir geht es um den Mapper, der aus beruflichen oder sonstigen Gründen irgendwo in der Pampa hockt. Seine Termine sind um 17 Uhr vorbei, den Rest des Abends verbringt er in der Kneipe oder im öden Hotelzimmer vor der Glotze. Straßen und Wanderwege der Umgebung sind gemappt, außerdem wird es dunkel. Vielleicht macht er noch einen Spaziergang bei gutem Wetter. Dann könnte er gezielt mal nachsehen, ob Laden xx noch aktuell ist, den hat seit 2 Jahren niemand mehr gecheckt. Vielleicht ist mir was entgangen... Aber gibt es überhaupt eine braubare Auswertung dafür? Bei meiner letzten Dienstreise stand ich kurz vor 20 Uhr vor dem Problem einen Supermarkt o.ä. zu finden um noch ein paar Besorgungen zu machen. Ich wäre froh gewesen eine Anwendung zu haben die in der Lage ist mir zu sagen welcher Lebensmittelmarkt in welcher Entfernung auf hat. Darin sehe ich auch die Lösung des Problems mit der Akualität. Ich habe keine Lust irgendwelche Öffnungszeitenschilder abzuklappern weil sie schon lange nicht mehr aktualisiert wurden sondern ich aktualusiere bei Bedarf vorwiegend die Dinge die mich persönlich interessieren. Und darunter fallen dann vorwiegend Dinge die auch in den Anwendungen auftauchen und weniger solche die für future use einfach nur in der Datenbank stehen. Wenn er das ohne weitere Infos macht, wird die Hauptstraße vorm Hotel alle 2 Tage gecheckt und der Rest vom Ort gar nicht. Auf Dienstreise möchte ich mich nach Feierabend ehr beim Entdecken von etwas neuem Entspannen als stupfsinnig Öffnungszeitenschilder abzuklappern... Ich bleibe dabei, dass ich einen solchen tag für sinnvoll halte. Niemand wird gezwungen, sich daran zu beteiligen. Die Idee dafür ist schon Jahre alt, wirklich etabliert hat sie sich aber wohl aus den Gründen nicht, die die Gegner hier anführen. Viel Aufwand für eine Datenaktualität die für den Anwender aber immer in der Vergangenheit liegen wird und so oder so sich selbst darum kümmern muss die wirklich aktuellen Daten zu erfahren. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
