Re: [Talk-at] Objekte mit start_date/end_date
On Mon, Nov 10, 2014 at 10:34:39PM +0100, Friedrich Volkmann wrote: 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. halte start_date/end_date für nicht ideal. Ein node/way kann mehrere tags haben, dann ist nicht klar worauf sich start_date/end_date beziehen sollen. Schon http://wiki.openstreetmap.org/wiki/Comparison_of_life_cycle_concepts gesehen? Mir gefällt eigentlich das tag:year-year Tagging ganz gut wobei ich year etwas allgemeiner mit Datum ersetzen würde. http://wiki.openstreetmap.org/wiki/Comparison_of_life_cycle_concepts#Related_concepts Richard ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Objekte mit start_date/end_date
On 10.11.14 19:13, Stephan Bösch-Plepelits wrote: 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??? Ich hatte das schon mal bei anderer Gelegenheit geschrieben: Es ist grundsätzlich NICHT sinnvoll, dass ein zweiter Tag die Beutung des ursprünglichen Tags umdreht, verändert, einschränkt, etc. Das war auf bei highway=primary, construction=yes das Problem, weshalb die jetzige Variante mit highway=construction, construction=primary noch die beste ist. Das ist auch ganz nachvollziehbar: Wenn ich eine Overpass-Query nach amenity=restaurant mache, dann will ich alle Restaurants. Und zwar die jetzt gültigen. Alles was vielleicht früher mal eins war, sollte jetzt sowas wie former:amenity=restaurant sein. So könnte man das auch bei den Admin-Boundaries lösen: alles, was jetzt gültige Grenze ist, ist boundary=administrative, alles, was früher mal war, former:boundary=administrative. Das Verändern des Keys hat übrigens Vorteile gegenüber einem Verändern der Value (siehe Beispiel highway=construction): Hieße der Key construction:highway=primary, würden bei der Query nach highway wirklich nur die jetzt gültigen Wege rausfallen, nicht eben auch die in Bau befindlichen oder gar die geplanten. Detto fallen bei amenity alle die ehemaligen POIs raus, die jetzt former:amenity sind. Macht Sinn, ist IMO die verträglichste Methode, nicht irgendjemand anderes Code zu brechen. /al ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Objekte mit start_date/end_date
Hi! Nichtsdestotrotz stehen jetzt gerade eben die tags start_date= und end_date= im admin_level=8 der Daten in Österreich. Prinzipiell find ich die Idee ja gut .. aber ich wäre ohne Stephan nicht auf die Idee gekommen und hab mich immer gefragt wieso da grad alles (also einiges) doppelt ausgespuckt wird (beim Checken auf Überlappungen im GIS). Gerade date wirft bei mir aber die Frage auf welches Format? Immerhin wird in verschiedenen Ländern das Datum auch unterschiedlich geschrieben. In Österreich steht es gerade als 2014-12-31 drinnen, was jetzt eher einer international Einheitlichen Schreibweise entspricht (zumindest ich würde als Österreicher das Datum andersrum schreiben). Mit dem Wissen das so etwas da ist ist für mich das Problem ja nun gelöst, aber ob und vor allem wie das richtig eingetragen gehört scheint ja noch nicht komplett geklärt zu sein. Danke für all die Info schon mal Liebe Grüße Werner 2014-11-11 13:13 GMT+01:00 Andreas Labres l...@lab.at: On 10.11.14 19:13, Stephan Bösch-Plepelits wrote: 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??? Ich hatte das schon mal bei anderer Gelegenheit geschrieben: Es ist grundsätzlich NICHT sinnvoll, dass ein zweiter Tag die Beutung des ursprünglichen Tags umdreht, verändert, einschränkt, etc. Das war auf bei highway=primary, construction=yes das Problem, weshalb die jetzige Variante mit highway=construction, construction=primary noch die beste ist. Das ist auch ganz nachvollziehbar: Wenn ich eine Overpass-Query nach amenity=restaurant mache, dann will ich alle Restaurants. Und zwar die jetzt gültigen. Alles was vielleicht früher mal eins war, sollte jetzt sowas wie former:amenity=restaurant sein. So könnte man das auch bei den Admin-Boundaries lösen: alles, was jetzt gültige Grenze ist, ist boundary=administrative, alles, was früher mal war, former:boundary=administrative. Das Verändern des Keys hat übrigens Vorteile gegenüber einem Verändern der Value (siehe Beispiel highway=construction): Hieße der Key construction:highway=primary, würden bei der Query nach highway wirklich nur die jetzt gültigen Wege rausfallen, nicht eben auch die in Bau befindlichen oder gar die geplanten. Detto fallen bei amenity alle die ehemaligen POIs raus, die jetzt former:amenity sind. Macht Sinn, ist IMO die verträglichste Methode, nicht irgendjemand anderes Code zu brechen. /al ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Objekte mit start_date/end_date
On 11.11.14 13:34, Werner Macho wrote: Nichtsdestotrotz stehen jetzt gerade eben die tags start_date= und end_date= im admin_level=8 der Daten in Österreich. Man hätte die zukünftigen mit future:boundary taggen können, vor allem sollte man aber zu Sylvester jene http://overpass-turbo.eu/s/5SQ rel(area.a)[boundary=administrative][end_date=2014-12-31]; auf former:boundary umtaggen. Gerade date wirft bei mir aber die Frage auf welches Format? http://wiki.openstreetmap.org/wiki/Key:start_date oder -mmoder -mm-dd oder div. Approximations sind definiert. /al ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Objekte mit start_date/end_date
On 11.11.2014 13:13, Andreas Labres wrote: Ich hatte das schon mal bei anderer Gelegenheit geschrieben: Es ist grundsätzlich NICHT sinnvoll, dass ein zweiter Tag die Beutung des ursprünglichen Tags umdreht, verändert, einschränkt, etc. Das war auf bei highway=primary, construction=yes das Problem, weshalb die jetzige Variante mit highway=construction, construction=primary noch die beste ist. Ich sehe das nicht so, dass start_date und end_date die *Bedeutung* verändern, sondern sie bringen nur eine vierte Dimension (Zeitachse) in OSM ein. Ob wir diese überhaupt haben wollen, ist eine andere Frage. Das ist auch ganz nachvollziehbar: Wenn ich eine Overpass-Query nach amenity=restaurant mache, dann will ich alle Restaurants. Und zwar die jetzt gültigen. Alles was vielleicht früher mal eins war, sollte jetzt sowas wie former:amenity=restaurant sein. So könnte man das auch bei den Admin-Boundaries lösen: alles, was jetzt gültige Grenze ist, ist boundary=administrative, alles, was früher mal war, former:boundary=administrative. Damit fehlt aber die Information, wann das existiert hat. Mit der Information alleine, dass es irgendwann existiert hat. lässt sich nicht wirklich was anfangen. Besser entweder ordentlich (mit Datum) oder gar nicht in der Datenbank halten, sonst ist es nur Datenmüll. Die Key-Prefixes construction: und former: erinnern mich an disused:, welches irgendwo im Wiki dokumentiert ist, aber von niemandem verwendet wird. Ich verwende nur disused=yes. Während disused:*=* dazu dient, etwas vor allen Anwendungen zu verstecken, will ich mit disused=yes nämlich erreichen, dass Anwendungen die Objekte sehr wohl noch sehen und nur anders darstellen, z.B. ausgegraut oder als Pfad statt als Track. Wenn ich will, dass Anwendungen etwas komplett ignorieren, dann lösche ich es ganz raus. Dafür brauche ich kein Tag wie disused, former oder construction. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Objekte mit start_date/end_date
On 11/11/2014 02:40 PM, Friedrich Volkmann wrote: On 11.11.2014 13:13, Andreas Labres wrote: Ich hatte das schon mal bei anderer Gelegenheit geschrieben: Es ist grundsätzlich NICHT sinnvoll, dass ein zweiter Tag die Beutung des ursprünglichen Tags umdreht, verändert, einschränkt, etc. Das war auf bei highway=primary, construction=yes das Problem, weshalb die jetzige Variante mit highway=construction, construction=primary noch die beste ist. Ich sehe das nicht so, dass start_date und end_date die *Bedeutung* verändern, sondern sie bringen nur eine vierte Dimension (Zeitachse) in OSM ein. Ob wir diese überhaupt haben wollen, ist eine andere Frage. Mit der vierten Dimension geb ich dir Recht, aber für mich lautet die Antwort spontan eher nein. Also ganz sicher nicht wenn das heißt, dass jeder, der die Daten verwenden will sich selbst um das Auswerten dieser vierten Dimension in all ihren Ausformungen (Formate, Zeitzonen, Sommerzeiten, etc.) kümmern muss. D.h. natürlich nicht, dass opening_hours oder so nicht in OSM sein sollten, denn die spezifizieren ja nur Eigenschaften eines konstant vorhandenen Objekts. Wenn ich aber an jedem Objekt mit einer Zeitinformation rechnen muss ab denen es nicht mehr existiert oder erst existieren wird, dann macht das die Auswertung deutlich komplizierter. Nicht unlösbar, aber imo absolut unnötig kompliziert. Wenn aber die Mapper das Gefühl haben, dass sowas wichtig ist, und sie unbedingt solche Zeiten eintragen wollen, dann sollte das imo in der API gelöst werden, so dass ich dann sagen kann, ich möchte aktuelle Daten zum Zeitpunkt t oder von mir aus in der Zeitspanne t+d haben. Ich persönlich verwend nur end_date und das nur auf Baustellen, die ich von name=Baustelle (mit allen möglichen wichtigen und vor allem unwichtigen Zusatzinfos) umgetagged hab und da seh ich das Datum eher als Note für andere Mapper. Noch dazu wo die Daten auf den Baustellenschildern ohnehin selten eingehalten werden, wenn die Baustelle nur groß genug ist. Imo sollte es für ein Crowdsourcing Projekt möglich sein Änderungen halbwegs zeitnah einzupflegen. Wenn das nicht passiert, dann war's wohl noch keinem wichtig genug, was eigentlich ein ganz guter Filter ist. Das ist auch ganz nachvollziehbar: Wenn ich eine Overpass-Query nach amenity=restaurant mache, dann will ich alle Restaurants. Und zwar die jetzt gültigen. Alles was vielleicht früher mal eins war, sollte jetzt sowas wie former:amenity=restaurant sein. Damit fehlt aber die Information, wann das existiert hat. Mit der Information alleine, dass es irgendwann existiert hat. lässt sich nicht wirklich was anfangen. Besser entweder ordentlich (mit Datum) oder gar nicht in der Datenbank halten, sonst ist es nur Datenmüll. Die Information ist ungefähr im Changeset enthalten. Wenn das nicht genau genug ist, dann kann man es auch an das Objekt selbst taggen, aber wenn man es zusätzlich zum former: Prefix tagged, dann ist allen geholfen. Denen, die nur nach aktuell gültigen Objekten suchen und denen, die ganz exakt wissen wollen, ab welchem Zeitpunkt die Daten veraltet waren. Aber eigentlich denk ich sollte alles in der DB sein was aktuell ist und dann geändert werden, wenn es sich geändert hat. Ganz ohne die Verrenkungen um alle möglichen Zustände seit es OSM gibt (oder gar noch viel länger) zu erfassen. Wer das braucht sollte die History auswerten. Norbert ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Objekte mit start_date/end_date
mh. also ich habe das bis jetzt so verstanden: start_date ist das baujahr, das zB auf brücken, häusern, marterln usw ja öfter anschrieben ist. liegt üblicherweise in der vergangenheit und ist eine info, die nur ausgewertet werden wird, wenn es jemand drauf anlegt. besonders dadurch interessant, da das meiste was gemappt wird ja schon um einiges länger existiert als die osmap. end_date ist das voraussichtliche ablaufdatum, so wie schon erwähnt bei baustellen und ähnlichem. könnte ausgewertet werden, aber sollte es eigentlich auch nicht. weil wenns nicht mehr da ist, wirds gelöscht bis auf den eventuell sinnvollen info-node. wer altdaten braucht, sollte im archiv wühlen. oder lieg ich da falsch? das bei den gemeindegrenzen diese beide nutzungen sich überschneiden und noch dazu der übergang der realität von einer sekunde auf die andere stattfindet ist aus meiner sicht ein *grenz*fall, den man eigentlich gemütlich grenzfall lassen sein kann. der wird in dem moment aufgelöst wenn sich am 1.1. der erste mapper daran erinnert, dass es ja jetzt komplett andere grenzen gibt und schnell eine wohlüberlegte query auf boundaries mit end_dates loslassen kann und dann ein paar veraltete relationen löscht bevor noch ein armer steierischer mensch an der falschen stelle mit seinem reisepass steht und nirgends einen grenzer sieht und dann in seinem restrausch von sylvester total verzweifelt und nicht mehr weiss was er machen soll. ;) grüsse, grubernd ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
[Talk-at] Objekte mit start_date/end_date
Hi! Heute ist uns aufgefallen, dass die neuen Gemeinden in der Steiermark bereits in der OpenStreetMap eingetragen sind und dort als start_date=2015-01-01. Die alten Gemeinden sind natürlich auch noch eingetragen und haben als end_date=2014-12-31. Das ist zwar durchaus nicht falsch, ich frage mich aber, ob irgendwelche Karten start_date/end_date derzeit auswerten - in normalen Karten (also denen, die start_date/end_date nicht auswerten) führt dies dazu, dass die Gemeinden jetzt doppelt vorhanden sind. Wäre es nicht sinnvoller die ehemaligen bzw. zukünftigen Gemeinden als boundary=future bzw. boundary=historic[1] zu markieren? [1] http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dhistoric Jemand müsste dann halt am 1.1.2015 die Gemeinden entsprechend austauschen. gruesse, Stephan -- Seid unbequem, seid Sand, nicht Öl im Getriebe der Welt! - Günther Eich ,-. | Stephan Bösch-Plepelits,| | Technische Universität Wien -Studien Informatik Raumplanung | | Projects: | | openstreetbrowser.org couchsurfing.org tubasis.at bl.mud.at | | Contact:| | Mail: sk...@xover.mud.at Blog: plepe.at | | Twitter: twitter.com/plepe Jabber: sk...@jabber.at | `-' ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Objekte mit start_date/end_date
On 10.11.2014 15:27, Stephan Bösch-Plepelits wrote: Heute ist uns aufgefallen, dass die neuen Gemeinden in der Steiermark bereits in der OpenStreetMap eingetragen sind und dort als start_date=2015-01-01. Die alten Gemeinden sind natürlich auch noch eingetragen und haben als end_date=2014-12-31. Das ist zwar durchaus nicht falsch, ich frage mich aber, ob irgendwelche Karten start_date/end_date derzeit auswerten - in normalen Karten (also denen, die start_date/end_date nicht auswerten) führt dies dazu, dass die Gemeinden jetzt doppelt vorhanden sind. Das ist dann ein Bug in den Karten. start_date und end_date sind so grundlegende Keys, dass jede Anwendung die berücksichtigen sollte. Die Aufgabe ist doch trivial. In einem ersten Programmblock alles mit start_date Stichtag, end_date Stichtag, hide=yes usw. ausfiltern. Das gleiche gilt übrigens fürs Auflösen der Strichpunkt-Notation. Die sollte sich schon herumgesprochen haben. Darum ist mir unbegreiflich, warum immer noch manche Anwendungen Probleme damit haben. Eine Zeichenkette an Strichpunkten aufzutrennen ist wahrlich keine Aufgabe, für die man viel vom Programmieren verstehen muss. Wäre es nicht sinnvoller die ehemaligen bzw. zukünftigen Gemeinden als boundary=future bzw. boundary=historic[1] zu markieren? [1] http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dhistoric Jemand müsste dann halt am 1.1.2015 die Gemeinden entsprechend austauschen. Die Forderung, jemand solle am Silvesterabend mit dem Finger über der Entertaste auf den Gongschlag warten um das Changeset genau in dem Moment hochzuladen, wenn andere mit Sekt aufs neue Jahr anstoßen und Glücksbringer austauschen, finde ich befremdlich. 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? Und sollen wir überhaupt Dinge mappen, die gar nicht mehr existieren? Der nächste mappt building=historic oder natural=water+water=historic. Das wird dann sehr unübersichtlich, denn z.B. im Wiener Becken war einmal ein Meer (Paratethys), das sich über die Jahrmillionen kontinuierlich zurückzug. Somit müsste man unendlich viele Küstenlinien eintragen. Ganz zu schweigen davon, dass Anwendungen, die nicht mal end_date berücksichtigen, dann solche Tags erst recht nicht verstehen. Das Wiener Becken wird in allen Karten blau werden. Wenn etwas nicht mehr existiert, und ich will es aus irgendeinem Grund noch in der Datenbank lassen (z.B. damit keiner das abgerissene Gebäude nochmal vom Orthofoto abzeichnet), dann lösche ich fast alle Tags und setze einen note=* (z.B. Gebäude wurde 2014 abgerissen). -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Objekte mit start_date/end_date
On Mon, Nov 10, 2014 at 06:36:43PM +0100, Friedrich Volkmann wrote: On 10.11.2014 15:27, Stephan Bösch-Plepelits wrote: Heute ist uns aufgefallen, dass die neuen Gemeinden in der Steiermark bereits in der OpenStreetMap eingetragen sind und dort als start_date=2015-01-01. Die alten Gemeinden sind natürlich auch noch eingetragen und haben als end_date=2014-12-31. Das ist zwar durchaus nicht falsch, ich frage mich aber, ob irgendwelche Karten start_date/end_date derzeit auswerten - in normalen Karten (also denen, die start_date/end_date nicht auswerten) führt dies dazu, dass die Gemeinden jetzt doppelt vorhanden sind. Das ist dann ein Bug in den Karten. start_date und end_date sind so grundlegende Keys, dass jede Anwendung die berücksichtigen sollte. Die Aufgabe ist doch trivial. In einem ersten Programmblock alles mit start_date Stichtag, end_date Stichtag, hide=yes usw. ausfiltern. 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. 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. 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??? Und sollen wir überhaupt Dinge mappen, die gar nicht mehr existieren? Sollen wir dann Dinge mappen, die noch gar nicht existieren? gruesse, Stephan -- Seid unbequem, seid Sand, nicht Öl im Getriebe der Welt! - Günther Eich ,-. | Stephan Bösch-Plepelits,| | Technische Universität Wien -Studien Informatik Raumplanung | | Projects: | | openstreetbrowser.org couchsurfing.org tubasis.at bl.mud.at | | Contact:| | Mail: sk...@xover.mud.at Blog: plepe.at | | Twitter: twitter.com/plepe Jabber: sk...@jabber.at | `-' ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Objekte mit start_date/end_date
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 ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
