1. 12 May, 2020 2 commits
    • Volker Krause's avatar
      Exclude the polar regions from the timezone index · 435da2ca
      Volker Krause authored
      This allows us to move about 20% of the available z-order curve length
      to more relevant regions, increasing the precision there.
      
      This however further increases the aspect ration to ~2.2, it might
      therefore make sense to use an additional bit for an initial split
      on the longitude to get this back to around 1. While this doesn't
      generally break the approach, the spatial proximity property of the
      z-order curve degrades a bit with this, reducing the encoding efficiency
      of this.
      435da2ca
    • Volker Krause's avatar
      Update to the 2020a timezone db release · 493ababa
      Volker Krause authored
      Also, use the zonetab file as the reference of our timezones, easier to
      work with and to debug than the QGIS files.
      493ababa
  2. 11 May, 2020 4 commits
  3. 10 May, 2020 4 commits
    • Volker Krause's avatar
      Use both the geo coordinate and the country to determine the timezone · 9b93d2ec
      Volker Krause authored
      When running this for all train stations in our database this gets very
      close to the expected timezones now, achieving 29789 matching results with
      only 9 deviations (some of those are mistakes, some are in disputed areas
      where the "correct" result isn't entirely obvious). Performance for
      airports is slightly worse, as those are more spread out over the world,
      and thus don't benefit as much from the fine-granular country structure
      in Europe that helps a lot here.
      
      There are some more ideas on how to further improve this, either way it
      looks very promising as a generic replacement for the timezone information
      in our static databases.
      9b93d2ec
    • Volker Krause's avatar
      Experimental geo coordinate to timezone mapping · 9650bb4c
      Volker Krause authored
      Conceptually this is a depth-limited quad tree. Practically this is
      implemented using a z-order curve and run-length encoding that in a
      vector together with the corresponding timezone.
      
      With the current settings the result is about 200kB, a maximum error
      distance of about 300m and a surface coverage of 99.2% for yielding the
      correct IANA timezone or 99.6% for yielding at least an equivalent
      IANA timezone. Not too bad considering the timezone shapefile that is
      the input for all this is 100+MB.
      
      Lookup cost is minimal, a single binary search and no memory allocations.
      
      The generation script is supposed to run inside QGIS with the IANA
      timezone shapefile loaded. With the current parameters it should finish
      within an hour on 8 cores.
      
      Before being fully integrated this needs a few more measurements with
      different parameters. Also still to be investigated is how this can
      replace the about 74kB worth of timezone data in the airport and train
      station databases.
      9650bb4c
    • Volker Krause's avatar
      Change the way we store timezones in the static database · 14800de9
      Volker Krause authored
      So far this were offsets into the the IANA string table, now it's a flat
      enum. The old way needed 13 bits per record, the new only needs 9 bit, at
      the cost of an extra ~800 bytes for an offset table to get back to IANA
      names. This however quickly pays of when storing large quantities, which
      we do (~37k in the current database, more in the upcoming experiments for
      an efficient geo coordinate to timezone mapping).
      14800de9
    • Laurent Montel's avatar
      GIT_SILENT: Time to increase version · dc9ed833
      Laurent Montel authored
      dc9ed833
  4. 09 May, 2020 1 commit
  5. 30 Apr, 2020 2 commits
  6. 24 Apr, 2020 1 commit
  7. 23 Apr, 2020 5 commits
  8. 22 Apr, 2020 4 commits
  9. 21 Apr, 2020 3 commits
  10. 20 Apr, 2020 2 commits
  11. 19 Apr, 2020 3 commits
  12. 18 Apr, 2020 6 commits
    • Volker Krause's avatar
      Handle more station types, and prioritize them · 30a73505
      Volker Krause authored
      This fixes the DEN and DUS tests, and makes some progress on PDX/HKG/PVG.
      30a73505
    • Volker Krause's avatar
      Look for stations slightly outside of terminal bounds as well · 412cfbea
      Volker Krause authored
      This fixes HAM, and should fix GDN/FRA/LIS too eventually, once the issues
      exposed there now get addressed.
      412cfbea
    • Volker Krause's avatar
      Also consider stations inside terminal buildings outside the airport bounds · b4911486
      Volker Krause authored
      This can happen when terminal buildings overlap the airport bounds. Fixes
      CPH for example.
      b4911486
    • Volker Krause's avatar
      Check the precise boundary for including terminals, not just the bbox · 91b4705e
      Volker Krause authored
      This removes terminal buildings from adjacent facilities from the
      consideration, such as the Airbus site next to TLS, or the government
      terminal next to TXL.
      91b4705e
    • Volker Krause's avatar
      Add a bunch of tests for optimized airport coordinates · 6479a49c
      Volker Krause authored
      This should help evaluate tweaks to the coordinate picking logic. With the
      current raw coordinates from Wikidata most of this fails (MUC being the
      exception), with the new OSM-based coordinate selection two thirds yield
      good results already.
      6479a49c
    • Volker Krause's avatar
      Initial experiments to improve airport coordinates based on OSM data · 4b5489d0
      Volker Krause authored
      So far the coordinates we use for navigating to/from airports come from
      Wikidata, and are typically somewhere on the center of the whole airport
      area, typically a runway. That's far from ideal for navigation, as that's
      neither a location you want to or event can get to, and in extreme cases
      this even leads to navigation "snapping" to the opposite side of the
      airport entirely.
      
      Instead we want a coordinate around somewhere around the entrance. So far
      there's three types of information from OSM we consider here:
      * terminal buildings (or rather the center point of their bounding box)
      * entrance nodes on terminal building polygons (unfortunately not reliably
      available in the input data).
      * railway stations on the premise of the airport.
      
      This improves the result for many smaller or mid-sized airports
      considerably already. What this cannot improve is the situation
      at large airports with widely spread terminals (LHR, CDG, MXP, etc).
      Those however cannot meaningfully represented by a single coordinate
      anyway.
      
      Code isn't hooked up yet, this is just for local experiments at this
      point.
      4b5489d0
  13. 17 Apr, 2020 1 commit
  14. 15 Apr, 2020 2 commits