Meiner Meinung nach hat der source-Tag aus genau diesem Grund nichts
in den map-Elementen zu suchen, sondern im Changeset:
On 26.09.2010 14:12, Georg Feddern wrote:
sinnvoll genutzt ist das Tag dann meines Erachtens aber nicht - und es
beist sich dann manchmal mit der Realität:
A1) Eine
Hallo Peter,
Meiner Meinung nach hat der source-Tag aus genau diesem Grund nichts in
den map-Elementen zu suchen, sondern im Changeset:
Das würde voraussetzen, dass in jedem Changeset nur eine einzige
Änderung erfolgt (ein Schlüssel oder Wert), und dass in der
Changeset-Beschreibung dann
Hallo Markus.
On 26.09.2010 15:13, Markus wrote:
Hallo Peter,
Meiner Meinung nach hat der source-Tag aus genau diesem Grund nichts in
den map-Elementen zu suchen, sondern im Changeset:
Das würde voraussetzen, dass in jedem Changeset nur eine einzige
Änderung erfolgt (ein Schlüssel oder
Hallo,
Am Sonntag 26 September 2010 14:12:11 schrieb Georg Feddern:
Moin,
Wolfgang schrieb:
Hallo,
Am Samstag 25 September 2010 11:21:46 schrieb Simon Kokolakis:
Am 25.09.2010 03:43, schrieb Wolfgang:
Das wäre das Datum der Erstaufnahme. Es geht aber darum, wann zuletzt
jemand
Am 26.09.2010 20:33, schrieb Wolfgang:
Diese Daten sind zwar 20 Jahre alt, aber keine Sorge, sie sind noch
richtig. Dafür halte ich das source-tag an sich für ungeeignet,
insbesondere
auch für Auswertungen.
Mit source:date_of_erfassung (vielleicht interessant, seit wann das Objekt
On 26.09.2010 21:52, Simon Kokolakis wrote:
Ich verstehe nicht warum hier immer zwischen ursprünglicher
Datenerhebung und Kontrollbesuchen unterschieden wird.
Ich denke, das Problem liegt darin, dass das source-Tag für einige als
unantastbar gilt:
Quellen, die eine Namensnennung fordern,
Hallo,
Am Sonntag 26 September 2010 21:52:45 schrieb Simon Kokolakis:
Am 26.09.2010 20:33, schrieb Wolfgang:
Diese Daten sind zwar 20 Jahre alt, aber keine Sorge, sie sind noch
richtig. Dafür halte ich das source-tag an sich für ungeeignet,
insbesondere auch für Auswertungen.
Mit
Am 25.09.2010 03:43, schrieb Wolfgang:
Das wäre das Datum der Erstaufnahme. Es geht aber darum, wann zuletzt jemand
vorbeigekommen ist und bestätigt, dass die vorhandenen Daten noch korrekt
sind.
Das stimmt m.E. nicht. Der Source tag sollte die Quelle der momentan
eingetragenen Information
Hallo,
Am Samstag 25 September 2010 11:21:46 schrieb Simon Kokolakis:
Am 25.09.2010 03:43, schrieb Wolfgang:
Das wäre das Datum der Erstaufnahme. Es geht aber darum, wann zuletzt
jemand vorbeigekommen ist und bestätigt, dass die vorhandenen Daten noch
korrekt sind.
Das stimmt m.E. nicht.
Am 25.09.2010 13:25, schrieb Wolfgang:
Ich würde den source-tag immer als Quelle und damit als Ursprung der Daten
sehen. In der Regel wird sich auch keine andere Quelle ergeben. Bei den
meisten hier in Frage kommenden POIs handelt es sich um Restaurants,
Einzelhändler etc. . Da ändert sich
Am 24. September 2010 20:02 schrieb Simon Kokolakis simon.kokola...@gmx.de:
Am 10.09.2010 21:02, schrieb Wolfgang:
Vorschlag:
last_check=2010-09
Gegenvorschlag: Den source-tag einfach mit Datum versehen, z.B.:
shop=electronics
source:shop=Survey 24.09.2010
+1, last_check ist nicht klar,
Hallo,
Am Freitag 24 September 2010 20:02:57 schrieb Simon Kokolakis:
Am 10.09.2010 21:02, schrieb Wolfgang:
Wir sollten Daten, für die die Gefahr besteht, dass sie sich unauffällig
verändern könnten, wenn wir sie schon erfassen, mit einem Aktualität-Tag
versehen, dass man gezielt z.B. für
In Gebieten mit hoher Mapperdichte mag das mit einem Aktualitätstag
realistisch sein. In Gegenden, wo die Mapper nur im Urlaub hinfahren hilft
das auch nichts.
Für den Nutzer ist es egal, ob der Laden vor 2 Jahren dicht gemacht hat,
oder vor einem Tag. Sprich das Risiko wird nie Null sein.
Hallo,
Am Samstag 11 September 2010 10:34:45 schrieb aighes:
In Gebieten mit hoher Mapperdichte mag das mit einem Aktualitätstag
realistisch sein. In Gegenden, wo die Mapper nur im Urlaub hinfahren hilft
das auch nichts.
Wenn ich mir für meinen Urlaubsort schon mal eine Checkliste ausdrucken
Hallo,
aighes wrote:
Daher denke ich, dass man eher versuchen sollte, die Anzahl der Kontrolleure
zu erhöhen und diesen ein vernünfteges und leicht erreichbares
Bug-Report-Werkzeug zur Hand geben. Das einfachste wäre, OSB auf die
Hauptseite zu bringen und auszubauen, sodass man mehr Daten
Wolfgang-4 wrote:
Wenn ich mir für meinen Urlaubsort schon mal eine Checkliste ausdrucken
kann,
weiß ich nicht, warum ich nicht gezielt die eine oder andere Information
aufnehmen sollte.
Wenn ich Urlaub mache, mache ich Urlaub. Sprich ich will keinen Zwang haben
und keine Liste zum
On Fri, Sep 10, 2010 at 09:02:31PM +0200, Wolfgang wrote:
Akzeptiert ein Supermarkt aber statt Karte A plötzlich Karte B, fällt das nur
dem auf, der mit Karte A zahlen wollte. Wenn der örtliche Mapper sowieso bar
zahlt, merkt der das höchstens zufällig. Vor Jahren hatte mal jemand die
Frederik Ramm wrote:
Hallo,
aighes wrote:
Daher denke ich, dass man eher versuchen sollte, die Anzahl der
Kontrolleure
zu erhöhen und diesen ein vernünfteges und leicht erreichbares
Bug-Report-Werkzeug zur Hand geben. Das einfachste wäre, OSB auf die
Hauptseite zu bringen und
On Sat, Sep 11, 2010 at 02:56:18PM +0200, M∡rtin Koppenhoefer wrote:
wobei access=no fast nie zutrifft, meistens ist es private oder
(motor_)vehicle=no, Stellen, wo wirklich niemand durch darf, gibt es
selten.
Wenn da das Weiss/Rote Spiegelei da steht ist das access=no oder nicht? Das
sich die
Am 11. September 2010 15:04 schrieb Florian Lohoff f...@zz.de:
On Sat, Sep 11, 2010 at 02:56:18PM +0200, M∡rtin Koppenhoefer wrote:
wobei access=no fast nie zutrifft, meistens ist es private oder
(motor_)vehicle=no, Stellen, wo wirklich niemand durch darf, gibt es
selten.
Wenn da das
Am Samstag 11 September 2010, 14:57:33 schrieb Kai Krueger:
Wenn sich keiner hinsetzt und den
Code dafuer schreibt und sicherstellt das er hochwertig genug und bugfree
ist um ihn in den Hauptzweig zu mergen, bringt das ganze gerede leider
nichts.
Jeah, wir schreiben alles in einer
Hallo,
Bernd Wurst wrote:
Jeah, wir schreiben alles in einer Programmiersprache, die zwar total hipp ist
aber die irgendwie trotzdem niemand freiwillig programmiert. Und dann suchen
wir Leute die allen möglichen Code beisteuern.
Und dann kommen doch glatt Leute und stellen fest, dass Teile
Hallo
ich sehe das Problem, dass das Mapping sich immer mehr Daten zuwendet, die
sich verändern können, ohne dass es jemand merkt.
Beispiel: Wird eine Straße umgebaut oder eine Tankstelle abgerissen, bekommen
das die Mapper recht schnell mit. Wechselt ein Restaurant von chinesisch auf
Am 10. September 2010 21:02 schrieb Wolfgang wolfg...@ivkasogis.de:
Was meint ihr?
das ist im Prinzip das alte Lied: wenn die Daten genutzt werden,
werden sie auch aktuell gehalten, wenn nicht, ist es sowieso egal ;-)
Am besten die Supermärkte aktualisieren selbst ihre Daten, genauso wie
die
Am 10.09.2010 um 21:25 schrieb M∡rtin Koppenhoefer:
Am 10. September 2010 21:02 schrieb Wolfgang wolfg...@ivkasogis.de:
Was meint ihr?
das ist im Prinzip das alte Lied: wenn die Daten genutzt werden,
werden sie auch aktuell gehalten, wenn nicht, ist es sowieso egal ;-)
Am besten die
Hi,
Am 10.09.2010 um 21:02 schrieb Wolfgang:
Hallo
ich sehe das Problem, dass das Mapping sich immer mehr Daten zuwendet, die
sich verändern können, ohne dass es jemand merkt.
Beispiel: Wird eine Straße umgebaut oder eine Tankstelle abgerissen, bekommen
das die Mapper recht schnell
Wolfgang wolfg...@ivkasogis.de wrote:
Vorschlag:
last_check=2010-09
Nein, ein tag ist IMO der falsche Ansatz! Das sollte in die API rein und
als Attribut an jedes Objekt dran.
Beim Anlegen eines Weges wird das dann auf das aktuelle Datum
gesetzt und hinterher kann jeder per Mausklick im Web
Hallo Wolfgang,
es ist immer wieder schön wenn man entdeckt, das gute Ideen wiedergefunden
werden.
Auch ich hatte vor ca. zwei Jahren die gleiche Idee, nur das mein tag
lastvisit heißen sollte.
Die Reaktionen damals reichten von Null bis negativ.
Mein Vorschlag:
1. Setze einfach das
Hallo,
Wolfgang wrote:
Beispiel: Wird eine Straße umgebaut oder eine Tankstelle abgerissen, bekommen
das die Mapper recht schnell mit. Wechselt ein Restaurant von chinesisch auf
griechisch, ist das auch recht schnell den örtlichen Mappern bekannt.
Schon da irrst Du vermutlich; zumindest hier
Am Freitag, den 10.09.2010, 21:02 +0200 schrieb Wolfgang:
Hallo
ich sehe das Problem, dass das Mapping sich immer mehr Daten zuwendet, die
sich verändern können, ohne dass es jemand merkt.
Beispiel: Wird eine Straße umgebaut oder eine Tankstelle abgerissen, bekommen
das die Mapper recht
Hallo,
am 10.09.2010 22:31 schrieb Frederik Ramm:
Ein einfaches last checked-Tag kann ein Anfang sein, aber ich sehe da
ein paar Probleme. Ueber kurz oder lang haben wir hier bei einem
Supermarkt getaggt, welche Karten er nimmt, wann er offen hat, wem er
gehoert, von welchem Lieferanten er
Hallo,
Am Freitag 10 September 2010 21:25:54 schrieb M∡rtin Koppenhoefer:
Am 10. September 2010 21:02 schrieb Wolfgang wolfg...@ivkasogis.de:
Was meint ihr?
das ist im Prinzip das alte Lied: wenn die Daten genutzt werden,
werden sie auch aktuell gehalten, wenn nicht, ist es sowieso egal ;-)
Hallo,
Am Freitag 10 September 2010 22:01:41 schrieb Sven Geggus:
Wolfgang wolfg...@ivkasogis.de wrote:
Vorschlag:
last_check=2010-09
Nein, ein tag ist IMO der falsche Ansatz! Das sollte in die API rein und
als Attribut an jedes Objekt dran.
Beim Anlegen eines Weges wird das dann auf
Am 10.09.2010 22:01, schrieb Sven Geggus:
Wolfgangwolfg...@ivkasogis.de wrote:
Vorschlag:
last_check=2010-09
Nein, ein tag ist IMO der falsche Ansatz! Das sollte in die API rein und
als Attribut an jedes Objekt dran.
Beim Anlegen eines Weges wird das dann auf das aktuelle Datum
gesetzt und
Am 10.09.2010 22:36, schrieb Andre Hinrichs:
Wenn die Anzahl der Mapper mit der gleichen Steigerungsrate wie bisher
zunimmt, funktioniert das eh von allein...
Ich fürchte, da übersiehst Du eine Kleinigkeit:
Wenn OSM erst mal richtig von den Marketing-Leuten wahrgenommen wird
dann wird man
Am 10.09.2010 21:02, schrieb Wolfgang:
Was meint ihr?
Telefonnummer, eMail- und Web-Adresse dürften da im Zweifel deutlich
besser helfen als
irgendwelche Aktualitäts-Tags.
Wenn auf diesem Weg niemand zu erreichen ist versuche ich es lieber bei
einem Mitbewerber
da nicht zu erwarten ist dass
On Fri, Sep 10, 2010 at 10:31:32PM +0200, Frederik Ramm wrote:
Darin beschreibt er, dass er viele Laeden, die er mal getaggt hat,
jetzt wieder loescht - weil er es fuer unrealistisch haelt, die
Information auf dem neusten Stand zu halten, und weil er keine
POIs fuer besser haelt als falsche
Garry garr...@gmx.de [Sat, Sep 11, 2010 at 12:33:25AM CEST]:
Am 10.09.2010 22:01, schrieb Sven Geggus:
Wolfgangwolfg...@ivkasogis.de wrote:
Vorschlag:
last_check=2010-09
Nein, ein tag ist IMO der falsche Ansatz! Das sollte in die API rein und
als Attribut an jedes Objekt dran.
Beim
38 matches
Mail list logo
