Jetzt muss ich doch nochmal fragen: Gibt’s bei der Online-Karte im Moment ein Render-Problem? Da gibt es einige Gebäude seit dem 5.2. die noch nicht erscheinen, Tiles sind nicht neu, auch wenn es seit dem schon mindestens zwei updates (laut About-Seite) gab. Z.B. hier: http://maps.osm2world.org/?h=128&view=N&zoom=18&lat=50.09335&lon=8.62549&layers=B0TTFF
(PS: Ja, die Gleise die da im Nichts enden mache ich noch fertig, beim letzten Versuch ist mir JOSM komplett abgeschmirt… sogar die automatische Sicherung war kaputt… )
Mueschel, der osm2world schafft es nur etwa 1 mal die woche, eine Ecke zu rendern. Meine Ecke macht er so alle 8 Tage nur. In deinem Bereich sind die Kacheln vom 6.2., da sollte er bald wieder rüber gehen (wenn es denn Änderungen gegeben hat).
Wenn du die Änderungen schneller sehen willst, hilft leider nur selber rendern…
Hmm ok, bei mir gibt es den komischen Effekt, dass ich den Eindruck habe, dass er nur ganz langsam Stück für Stück die Änderungen anwendet. Also quasi nicht mit einem Schlag die gesammte Karte, sondern für einen Bereich häufig nur einen Stand, der schon lange nicht mehr aktuell ist.
@Tordanik magst du ganz kurz erklären wie bei euch Updates eingespielt werden?
Vielleicht hängt das aber auch mit den anderen Problemen zusammen. Die Geofabrikupdates hatten ja auch gerade Probleme und diese sind die Grundlage für den Server.
Zur Erklärung was wir machen: Wir laden einen Dump von Frederik herunter und zerteilen den in lauter Datenfiles der Größe z=13. Das Datum des Dumps steht in der About-Seite und enthält Daten, die da bereits ca 1-2 Tage alt sind. Dann kommen die Renderserver und suchen sich per Zufallsgenerator eine Kachel aus und rendern diese (das ist dann das Datum, dass im Timestamplayer steht). Wenn alle Kacheln gerendert wurden (dauert 3-7 Tage) dann wird ein neuer Dump heruntergeladen. Im übrigen werden nur die Datenkacheln gespeichert und somit gerendert, die sich geändert hatten, d.h. die Menge an Arbeit hängt auch von der Anzahl an Änderungen ab.
Ich denke das passt so schon. Das letzte mal wurde die Kachel am 6.2. gerendert, leider kann ich nicht mehr nachschaun, wie aktuell die Daten zu diesem Zeitpunkt waren. Das werden wir demnächst noch ändern um das etwas transparenter zu gestalten. Der neue Dump von gestern sollte deine Daten sicher enthalten und beim nächsten Rendern dieses Tiles (Zufallgenerator, spätestens in 3 Tagen) sind deine Daten dann auch sicher dabei. Falls nicht, gäbe es wirklich einen Bug.
Das passiert leider manchmal. Habe ich mal manuell gefixt.
ca. 1 Tag alten Dump laden, 2. geändertes neu rendern, 3. warten auf nächsten Dump
hatte einer von euch ja schonmal gepostet, soweit ist das auch klar. Ein Absatz über den Ablauf auf der About-Seite sollte völlig reichen für die Transparenz, insbesondere das Alter des Dumps ist für den ungeduldigen User wichtig zu wissen.
Gerendert am 6.2. um 6 Uhr, Dump-Datum war etwa drei Stunden früher (klar, hier sind die Änderungen vom 5.2. noch nicht drin). Dann gabs laut About einen Dump vom 12.2. und gestern stand da dann der 15.2. Evtl. noch einen Dump dazwischen den ich nicht mitbekommen habe.
Btw., wäre es möglich ein paar mehr Gebäudetypen mit default-Werten zu versehen? Ich benutze hier z.B. relativ häufig shed für Gartenschuppen und die sehen mit 10 Metern Höhe einfach merkwürdig aus. Vielleicht kann man einen default von 2.5 m und brauner Farbe machen?
Da wäre ein est_height=2.5 (wird bei OSM2World ausgewertet) deutlich einfacher. Das ist näher an der Realität und verschiebt nicht die Verantwortung auf den Renderer.
Das Problem ist, dass man mit Default-Werten auch heftig daneben liegen kann.
Du magst das so wie im Wiki beschrieben nutzen. Andere mögen das als Synonym für Scheune (barn) verwenden, da das nicht bei building definiert ist. Dann wäre damit ein Gebäude-Typ mit meist zwei Stockwerken gemeint.
Das erste was ich dachte war: Vom Regen in die Traufe.
Denn est_height ist m.E. eine komplett undokumentierte Eigenschaft.
Außer in dieser Tabelle konnte ich in der schnelle nix darüber finden.
Das ist doch eigentlich mein Part, auf solche Unzulänglichkeiten hinzuweisen.
Allerdings sehe ich im Vergleich zu est_width keine Gründe, das auch analog für length oder height zu nutzen. Man könnte natürlich auch height=* + source:height=estimation schreiben. Das scheint mir aber bei weitem nicht so klar zu sein. Wer wertet denn zusätzlich das source:* noch aus?
Da bin ich absolut dagegen. Dann brauchen wir noch est_material (wenn ich es nur gesehen, aber nicht angefasst habe), est_color (wenn es schon dämmrig war beim Betrachten) und in den meisten Fällen ein est_roof:type, weil man das Dach meist nur von der Straße aus sieht und die Rückseite raten muss.
Die Höhe ergibt sich aus der Definition des Gebäudetyps. Alles andere gaukelt nur Informationen vor, die in Wirklichkeit gar nicht vorliegen. Wenn ich est_height setze, dann heißt das, ich habe danebengestanden, und bin mir über die Höhe sicher, hatte aber gerade keinen Zollstock dabei. Über den Typ ‘shed’ kann ich aber auch Aussagen treffen, wenn ich in 50 Meter Entfernung vorbeigegangen bin oder sogar nur ein Luftbild hatte.
Ein shed ist im wiki eindeutig definiert, sogar ohne irgendwelche Mehrdeutigkeiten in den Übersetzungen die ich lesen kann. Wenn das jemand falsch benutzt ist das kein Problem, das ein renderer beachten muss. Eine Scheune ist ebenso eindeutig farm_auxiliary (auch wenn ich ‘barn’ gut fände).
@EvanE: Die Unzulänglichkeit ist in meinen Augen die, dass man est_* garnicht braucht. Es macht dem Renderer/3D-Interpreter die Arbeit nur schwerer, schließlich muss dafür dann eine extra Regel geschrieben werden. Doch eigentlich ist das unnötig, denn ein bestimmtes Objekt kann nur eine Höhe haben. Ob dies eine gemessene oder geschätze ist, spielt keine Rolle. Es ist nur für den Mapper interessant, da dieser dann die Info erhält, dass hier der Bedarf für einen exakteren Wert besteht. Doch eben der Mapper kann lesen und das Attribut “source:height” auch auswerten. Daher tendiere ich zur Verwendung von
Auf der Seite “key:height” steht daher auch: Die Quelle der Höhenangabe kann mittels source:height= definiert werden.*
Dies führt dazu, dass diese Tabelle ein Stück übersichtlicher wird und der Mapper nicht ausversehen height und est_height gleichzeitig verwendet, was wieder zu einer zusätzlichen Interpretationsregel führen würde.
Leute, wollen wir tagging-Diskussionen zu 3D nicht auslagern? Das ist doch nichts spezifisches von O2W und gehört eigentlich zur Thematik allgemeines 3D. Wenn ihr das nur hier schreibt, dann geht es doch total unter?
@Peda Nein kein Problem wenn du antwortest Danke auch gleich für die Erläuterungen! Gibt es einen bestimmten Grund, wieso vom Scheduler die Gebiete zufällig ausgewählt werden? Es wäre später vielleicht gut, wenn Gebiete mit vielen/gravierenden Änderungen vielleicht schneller/häufiger aktualisiert werden?
Ich weiß das klingt nach Wunschliste, aber habt ihr mal geschaut, ob euch jemand hilft eine DB aufzusetzen, die sich permanent aktualisiert?
Darf ich fragen, ob man demnächst evtl. den Kanton Freiburg wieder neu rendern kann? Ich habe letzthin ein paar 3D-Änderungen vorgenommen und würde gerne sehen, ob diese o.k. sind. Danke.
Mache ich ansich regelmässig aber es gibt immer keine Änderungen. Laut unseren Skripten sind die letzten Änderungen die in OSM gemacht wurden vom 3.2.2013. Ich nehme also fast an, dass da was mit Frederiks Dump für die Schweiz nicht ok ist. Ich werde das mal weiter untersuchen bzw. Frederik anschreiben/fragen.
Könnte man vielleicht die Priorität einiger Gebiete durch Pizza-Spenden günstiger beeinflussen? Ich warte schon sehnsuchtsvoll auf Warnemünde und die Rostocker Innenstadt
Vielen Dank, dass Du Dich dieser Sache annimmst. Jedenfalls zwischen 05.02 und 13.02 habe ich doch einiges an 3D-Daten hinzugefügt/geändert in meiner Region - siehe z.b. meine Edits hier: http://www.openstreetmap.org/user/efred/edits?page=2.
)
Ich warte schon sehnsuchtsvoll auf Warnemünde und die Rostocker Innenstadt 