Zwei Ideen zum Thema:
1) delayed notes: Eine note bei der ich ein Datum eingeben, wann sie
sichtbar wird.
2) ich benutze das source tag um anzugeben, dass ich Gebäude verschoben
habe (oder neu hinzugefügt habe) in der Form:
source:position=Esri World Imagery
Hintergrund: in meiner Gegend sind
Ich bin nicht der Meinung, dass so etwas gar nichts mit Geodaten zu tun
hat, auch wenn nicht direkt. Dann müssten Daten wie Zeitpunkt der
Eintragung Änderungsdaten usw auch verschwinden, denn sie haben direkt
genausowenig damit zu tun wie die Speicherung der Changesets und Quellen.
All diese
Ich bin nicht sicher, ob Datenbank-timestamps nicht der falsche Weg sind.
Nach meinem Gefühl (mehr ist es im Moment nicht) sind das automatisiert
erzeugte Metadaten, die die Datenbank für ihre interne technische
Integritätsprüfung bzw. nachweis braucht.
Das habe-gecheckt-Tag wäre aber doch
das Dateum einer Verifikation ist keine "natürliche Eigenschaft" eines
geographischen Objektes => hat mit dem Objekt in physikalischer Weise
nichts zu tun. Und genau das beschreiben wir is OSM => hat also m.E.
eindeutig nichts in der DB zu tun.
Just my 2 cents,
Michael.
Am 11.08.2018 um 13:08 schrieb Andreas Meier:
die Information eines
Verifikationsdatums ist m.E. eine Information, die an das Objekt gehört,
weil sie als Metadaten die Qualität der Objektdaten beschreibt.
das Dateum einer Verifikation ist keine "natürliche Eigenschaft" eines
geographischen
Nochmals: ich bezog mich nur auf die node_tags, way_tags und
relation_tags Tabellen! Die Position wird ja nur in nodes gespeichert
und hat einen eigenen timestamp. Und da die node_tags über node_id und
version mit nodes verbunden ist, würde ich eben die version beibehalten,
aber eben den (noch zu
sent from a phone
On 12. Aug 2018, at 11:19, Harald Hartmann
wrote:
>> d.h. neue Version, die gleich ist wie die vorherige, oder?
>
>
> nicht zwingend, da sich ja nichts geändert hat, würde ich persönlich die
> Version(snummer) belassen und nur das Datum ändern. ... klar, dass
> könnte von
Hallo Harald,
> Diese ganzen Extra Tags um ein Datum für eine Wertänderung anzugeben
> braucht es eigentlich überhaupt nicht ... und bläht die Datenbank in der
> Tat unnötigerweise auf.
Wenn es bessere Wege gibt gern :-)
> Was es braucht, ist entweder eine Datenbankänderung, oder eine
>
>> 1. Variante mit der Datenbankänderung auch via API die Möglichkeit, den
>> timestamp bewusst für ein Tag "up-to-date" zu setzen, wenn man es
>> einfach nur kontrolliert/gechecked hat.
>
>
> d.h. neue Version, die gleich ist wie die vorherige, oder?
nicht zwingend, da sich ja nichts geändert
sent from a phone
> On 12. Aug 2018, at 10:47, Harald Hartmann
> wrote:
>
> 1. Variante mit der Datenbankänderung auch via API die Möglichkeit, den
> timestamp bewusst für ein Tag "up-to-date" zu setzen, wenn man es
> einfach nur kontrolliert/gechecked hat.
d.h. neue Version, die gleich
in der letzten Mail ganz vergessen: natürlich bräuchte man dann bei der
1. Variante mit der Datenbankänderung auch via API die Möglichkeit, den
timestamp bewusst für ein Tag "up-to-date" zu setzen, wenn man es
einfach nur kontrolliert/gechecked hat.
Die 2. Variante (ermittlung des letzten Datums)
Diese ganzen Extra Tags um ein Datum für eine Wertänderung anzugeben
braucht es eigentlich überhaupt nicht ... und bläht die Datenbank in der
Tat unnötigerweise auf.
Was es braucht, ist entweder eine Datenbankänderung, oder eine
Anwendung, die das letzte Datum ermittelt.
1. Datenbankänderung:
sent from a phone
> On 11. Aug 2018, at 13:08, Andreas Meier wrote:
>
> Bei lastcheck:note =* habe ich im Moment Fragezeichen, ob das als
> unstrukturiertes Tag nötig und hilfreich wäre.
der note tag als Freeform tag um weitere Informationen unstrukturiert an
folgende Mapper weiterzugeben,
Der Stammtisch Bochum würde mir offenbar gefallen :-)
Einen entsprechenden Kommentar im Changeset für dann ein Objekt fände ich
aus Modellierungsaspekten nicht logisch: die Information eines
Verifikationsdatums ist m.E. eine Information, die an das Objekt gehört,
weil sie als Metadaten die
Hallo Gisbert,
prima Ergänzung vom:
> Stamtisch in Bochum
:-)
> zur Zeit gibt es viele verschiedene Tags.
Am Besten wäre es, diese Q-Tags im Wiki genau zu beschreiben/definieren:
Nur genau definierte tags sind hilfreich.
(sonst bekommt am die gleichen Konflikte und Endlosdiskussionen, wie wir
genau das war am letzten Stamtisch in Bochum Thema.
Da wurde das ganze deshalb angefragt weil wir uns vermehrt um
Öffnungszeiten kümmern wollen. Die Möglichkeiten von QA sind derzeit ja
nur vorhanden oder nicht abzufragen.
Unsere Zusammenfassung erbrachte dann ein paar wenige Fakten.
Sinnvoll
Hallo Andreas,
> häufig sind vorhandene Tags veraltet und falsch.
> sinnvoll: Zeitstempel der letzen Überprüfung
> Damit könnte ich mir alle Objekte herausfiltern, die z.B.
> länger als ein Jahr nicht überprüft wurden und gezielt hinfahren.
:-)
Das macht man in jedem
sent from a phone
> On 11. Aug 2018, at 00:05, Andreas Meier wrote:
>
> Gibt es dazu Meinungen? (Wenn das
> schon 100 Mal diskutiert wurde, dann wäre ich für einen Hinweis auf das
> Ergebnis dankbar)
ja, das wurde schon öfters mal vorgeschlagen.
Es gibt z.B. diese metadaten tags in
Da wirst Du Dich wohl darauf verlassen müssen, dass das Datum der
letzten Änderung auch das Datum der letzten Überprüfung der Leerungszeit
ist. Jeder zusätzliche Tag würde die Datenbank nur mit sinnlosen Daten
füllen, die nichts mit Geodaten zu tun haben
Am 11.08.2018 um 00:05 schrieb
Hallo zusammen,
seit einiger Zeit tagge ich auch collection_times bei Briefkästen. Durchaus
häufig sind vorhandene Tags veraltet und falsch. Leider kann ich den
Briefkästen nicht ansehen, ob die collection_times letzte Woche oder vor 4
Jahren zuletzt überprüft wurden. Bestenfalls gibt es ein
20 matches
Mail list logo
