Update

  • Import von Nodes:
    • ev. young generation vergrössern(Memory jvm flag -XX:NewRation=...; -XX:NewSize=...)
    • Meiste Zeit wird verbracht in
      • org.postgresql.core.VisibleBufferedInputStream.readMore(int),33.082973%
      • ch.hsr.osminabox.db.sql.util.DBUtil.castValue(Object, Class),20.940252%
      • ch.hsr.osminabox.db.sql.util.DBUtil.validateValue(ch.hsr.osminabox.db.dbdefinition.Column, String),14.040529%
    • Ev Parallelisierung?
  • Import von ways
    • 80% Zeit in org.apache.commons.httpclient.HttpParser.readRawLine(java.io.InputStream)
    • Vermutlich warten auf OpenStreetMap server
    • Idee: Parallelisierung
  • Löschen von Relationen und Ways, die nicht in der BB sind dauert sehr lange und 96%! der zeit wird auf die DB gewarted, genauer gesagt bei
org.postgresql.core.VisibleBufferedInputStream.readMore(int)
  • Allgemeine Vermutungen
    • Objekte ausserhalb der Bounding-Box werden zuerst in die DB geschrieben und anschliessend wieder gelöscht
      • Nach Abklärung, alle Nodes und Ways werden auf zuerst in die node_temp, bzw. way_temp geschrieben, in JEDEM fall. Sind die Objekte zudem in der BoundingBox, so werden sie erst auf mappings und danach in die jeweilig in den mappings spezifizierten Tabellen geschrieben. --> Die hat den Grund, dass ja nodes später ev. in ways vorkommen könnten und ways von relationen referenziert werden könnten. Hier kann sicher optimirt werden, als dass nicht ALLE Nodes und Ways in die DB müssen(was viel Zeiteinsparung bedeuted)
    • Falls Teile nicht vorhanden sind, werden diese vom Webservice nachgeladen --> Dummerweise wurden wird, da zu viel Traffic, gesperrt, deshalb schalter --no-consistency implementiert.
  • Fragen?
    • Was geschieht mit Objekten, die auf der Bounding-Box sind?
      • In Doku abgeklärt --> werden ways und areas werden importiert, so bald sich ein NODE in der BB befindet.