> Gesendet: Sonntag, 22. April 2018 um 08:20 Uhr > Von: mmd <mmd....@gmail.com> > An: talk-de@openstreetmap.org > Betreff: Re: [Talk-de] Flächen/Wege // Trolling in changesets > > Ihr müsst einfach mal schauen, welche Datenmengen dahinter stecken. > Momentan schleppen wir 4,4 Milliarden Nodes mit uns herum, davon 3,8 > Milliarden Nodes, die nur in irgendwelchen Ways vorkommen, [..]
Bis auf die Verweise und evtl. irgendwelche Metadaten (die aber für attic + history Zwecke immer interessant bleiben) sehe ich nicht, wie durch diese Verlagerung irgendetwas eingespart werden soll. Du sprichst hier nur von einer lat/lon-Information, aber so einfach ist das nicht. Ein node-Objekt kann auch eine Historie mit mehreren Revisionen haben, die u.U. für Mapper aber auch Anwender interessant sein kann. Außerdem erfüllt das node-Objekt in hohem Maß den Bedarf, es zu editieren, es in den Knotenlisten der Wege neu einzuordnen, zu verschieben oder eben von einem weiteren Weg (Kreuzung oder Straße über Straße (elevated high- way)) referenziert zu werden. Du schreibst, dass dieser Aspekt durch ein Hybrid-Modell erhalten bliebe. De facto bedeutet es für jeden Edit- vorgang, dass Koordinaten ihren Status wechseln können (müssen), d.h. von way-gebundener Koordinate zu eigenständigem Node wahlweise promo- vier- oder eben herabstufbar sein müssen. > Jedes Tool muss sich momentan einen riesigen Cache aufbauen, der zu der > Node Id die entsprechenden Koordinaten zurück liefert, damit überhaupt > klar ist, wie die Geometrie eines Ways aussieht. Das ist für den vorwiegenden Anwendungsfall, einen relativ kleinen Daten- ausschnitt zu laden, etwas zu verändern und es wieder hochzuladen häufig nicht relevant, macht sich aber evtl. als Skaleneffekt bemerkbar, wenn etwa der gesamte Planet verschnitten werden soll. Warum versucht man nicht, die Vorteile, die sich durch diese Umverlagerung ergeben können, durch eine Art Vorverarbeitung der Daten zu nutzen, die sich dann nur damit beschäftigt, die Nodes je nach ihrer Verwendung in das Modell des neuartigen way-Typs einzuordnen, bzw. ident zu belassen? Es hört sich so an, als wenn so ein Hybrid auch mit den laufend verfügbaren Changesets aktuell gehalten werden kann, was die Änderungsmenge nach einem initialen Import minimiert. Auf diese nebenläufige DB, die alle Änderungen im Abo bezieht, diese aber wegen des geänderten Datenmodells erst nach Transformation/Vorverarbeitung übernimmt, kann dann lesend zugegriffen werden (ob von Dumping- oder Edit- Tools), womit sich parallel bequem Tools weiterentwickeln ließen, die dann alternativ das hybride Modell verarbeiten. Der (zu entwickelnde..) Daten-Trafo wäre Dreh-/Angel- und Einstiegspunkt. Wenn im Trafo alle ways, die von einem Changeset geändert wurden, so um- gerechnet werden können, dass kein Zugriff auf die Ziel-DB erfolgt, dann darf die Wandlung Node->Koordinate eine Einbahnstraße sein. Das heißt ein Mapping von Koordinate zu früherer Node-Id wäre dann für die Änder- barkeit der ways in der Ziel-DB verzichtbar. Dennoch, während zu Nodes promovierte Koordinaten durch diesen Trafo ihre History dann einfach von A nach B kopieren könnten, wenn sie in B vorher nur Koordinate waren, bedeutet das für einen späteren Live-Betrieb ohne A, dass eine History (und Metadaten) für Nodes nicht mehr sinnvoll beibehalten werden kann - es sei denn diese wird bei einer Abstufung mit in (alle!) ways geschrieben. Die zu behandelnden Edit-Fälle sind zahlreich, man denke an das Verbinden und Trennen von gemeinsamen Wegknoten. Um Erfahrungen zu sammeln, wäre das aber ein möglicher Pfad, der sich gehen lässt, ohne den derzeitigen Live-Betrieb zu beeinträchtigen, imho. Gruß _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
