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
sent from a phone
> On 12. Aug 2018, at 18:12, chris66 wrote:
>
> Ja, das ist meine Meinung.
>
> Es handelt sich um Privatwege die der Bewirtschaftung der Kanäle dienen.
> Fußgänger und Radfahrer sind auf eigene Gefahr erlaubt.
>
> typisches Tagging:
>
> highway=track
Mal ketzerisch
Am 09.08.2018 um 09:57 schrieb Christoph Hormann:
Bei highway=track ist die land- und forstwirtschaftliche Nutzung
übrigens keine abschließende Aufzählung von möglichen Nutzungen, im
Englischen steht da ein 'etc.' dran. Hier kann man die
wasserwirtschaftliche Nutzung in Analogie durchaus mit
Am 08.08.2018 um 18:16 schrieb Florian Lohoff:
entlang des
Datteln-Weser-Kanals sind das tracks.
Ja, das ist meine Meinung.
Es handelt sich um Privatwege die der Bewirtschaftung der Kanäle dienen.
Fußgänger und Radfahrer sind auf eigene Gefahr erlaubt.
typisches Tagging:
highway=track
On Sat, Aug 11, 2018 at 12:36:25AM +0200, Andreas Meier wrote:
> Ich könnte sowohl mit Track oder Service gut leben, aber aus den bisherigen
> Argumenten leitet sich ggf. eine Empfehlung ab:
> > Die Abgrenzung track zu service: letzteres ist es dann, wenn es keiner
> > höheren Klasse angehört und
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:
14 matches
Mail list logo
