[Talk-at] Objekte mit start_date/end_date

[Friedrich Volkmann]

On 10.11.2014 19:13, Stephan Bösch-Plepelits wrote:
> Nun, ich stimme zu, dass es trivial ist. Das heisst aber noch nicht, dass
> es auch getan wird. Nur als Beispiel, openstreetmap-carto, der Standardstil
> der OpenStreetMap, berücksichtigt start_date und end_date nicht.

Wir können ein Ticket erstellen.

>> Das gleiche gilt übrigens fürs Auflösen der Strichpunkt-Notation. Die sollte
>> sich schon herumgesprochen haben.
> Das Problem ist weniger das Auflösen, sondern was dann damit gemacht werden
> soll. ZB. was bedeutet highway=primary;pedestrian? Meiner Ansicht nach
> macht das nur für bestimmte Tags Sinn, zB. cuisine. Aber dort ist das
> meines Wissens eh dokumentiert.

Der einfachste Ansatz ist es, alles ab dem ersten Strichpunkt wegzuwerfen.
Z.B. highway=primary;pedestrian wird dann nur als primary dargestellt, oder
(was Realistischeres) amenity=cafe;restaurant nur als Kaffeehaus.

Für eine Suchfunktion ("zeig mir alle Restaurants in der Umgebung") kann es
geschickt sein, das Objekt in der Anwendungsdatenbank (nicht in OSM !) zu
verdoppeln, es also 1x als amenity=cafe und 1x als amenity=restaurant drin
zu haben.

>> Und boundary=historic ist ein dubioses Nonstandard-Tag. Woran soll eine
>> Anwendung erkennen, um was für eine Art von Grenze
>> (administrative/protected_area/postal_code/etc.) es sich handelte?
> Nun, man könnte analog etwas wie bei Straßen machen. Dort ist ja während
> der Bauzeit highway=construction, construction=primary eingetragen. Nach
> Eröffnung wird das dann umgetaggt. Also vielleicht boundary=construction,
> construction=administrative???

Mir gefällt schon highway=construction nicht. Das ist von konventionellen
Karten abgeschaut, wo es üblich ist, in Bau befindliche Straßen
einzuzeichnen. Das Tagging an kartografische Traditionen anzulehnen hat uns
auch in anderen Fällen Probleme bereitet (z.B. "signifikante" Bäume).

Dieses Schema x=y -> x=construction + construction=y funktioniert nur dort,
wo das Haupttag eindeutig ist. Bei building=yes + amenity=restaurant ist es
nicht mehr so klar. Wenn das Gebäude in Bau ist, ist zugleich auch das
Restaurant noch in Bau. Vielleicht gibt es Anwendungen, die nur
amenity=restaurant auswerten und building=* ignorieren, oder umgekehrt.

>> Und sollen wir überhaupt Dinge mappen, die gar nicht mehr existieren?
> Sollen wir dann Dinge mappen, die noch gar nicht existieren?

Das ist ein guter Punkt. Und wenn es z.B. um die Verlegung einer Grenze oder
einer Buslinie geht, dann wird es mühsam und sehr fehlerträchtig, die alte
und die neue Variante gleichzeitig in OSM zu haben.

Ich denke, dass Änderungen, die in real in naher Zukunft wirksam werden, in
OSM schon vorweggenommen werden können. Beispiel: Die Gemeinde Weißenkirchen
an der Perschling wird umbenannt, und ich hab sie schon umgetaggt. Denn
besser zu neue als zu alte Daten. Die meisten Anwendungen kommen sowieso mit
einem älteren Datenabzug zum User, oder die Daten werden nicht regelmäßig
aktualisiert.

Aber wenn die Änderung weiter in der Zukunft liegt, dann ist es mitunter
besser, einen Map Note als Merker zu setzen. Jemand hat auf der
Wienerbergstraße eine Straßenbahn eingetragen, die erst in Planung ist.
Vielleicht wird die Planung noch geändert, wer weiß. So eine Straßenbahn in
der Karte zu sehen, ist für die meisten Anwender nur irritierend. Deshalb
hat jemand die Straßenbahn wieder rausgelöscht.

-- 
Friedrich K. Volkmann       http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria