1. 22 Feb, 2021 3 commits
  2. 21 Feb, 2021 1 commit
  3. 19 Feb, 2021 1 commit
  4. 01 Feb, 2021 1 commit
  5. 31 Jan, 2021 1 commit
  6. 31 Dec, 2020 1 commit
  7. 19 Dec, 2020 1 commit
  8. 09 Nov, 2020 1 commit
  9. 22 Oct, 2020 1 commit
  10. 25 Jul, 2020 1 commit
    • Volker Krause's avatar
      Fix the side-effects of openSUSE adding an Asia/Beijing timezone · 3023ed77
      Volker Krause authored
      Other systems don't have that and instead use Asia/Shanghai as defined
      in the timezone database. This caused different timezone lookup results
      in the vicinity of China on those systems, like in the HKG test.
      We no explicitly check for this when generating our timezone tables.
  11. 24 Jul, 2020 1 commit
    • Volker Krause's avatar
      Add Benerail station ids to the train station database · 4e5c7076
      Volker Krause authored
      This is now possible that Wikidata got that information, and enables for
      example Thalys barcodes to be matched to the correct stations.
      This also includes a bit of refactoring of the station identifier db
      generation to get rid of some of the code duplication there.
  12. 06 Jul, 2020 1 commit
  13. 30 Jun, 2020 1 commit
  14. 22 Jun, 2020 1 commit
  15. 27 May, 2020 1 commit
  16. 26 May, 2020 1 commit
  17. 20 May, 2020 1 commit
  18. 19 May, 2020 1 commit
    • Volker Krause's avatar
      Switch from Gares & Connexion (P3104) to SNCF station codes (P8181) · debbe6c2
      Volker Krause authored
      SNCF station codes a strict superset, and also cover e.g. foreign stations
      not managed by Gares & Connexions, and thus is what we actually want here
      to make international tickets work as well. This only recently became
      available in Wikidata though.
      This does not contain the actual db update yet, that will happen as part
      of the removal of the explicit timezone information.
  19. 18 May, 2020 1 commit
  20. 15 May, 2020 1 commit
  21. 14 May, 2020 2 commits
  22. 13 May, 2020 1 commit
    • Volker Krause's avatar
      Store whether we have an unambiguous or equivalent timezone · d5dadf11
      Volker Krause authored
      This uses the last bit we still had unused in the index, but due to the
      extra information impact the run-length encoding and thus slightly
      increases the number of entries.
      Having this available however allows us to further increase precision,
      and gives us a coordinate to country mapping essentially for free.
  23. 12 May, 2020 3 commits
  24. 11 May, 2020 1 commit
    • Volker Krause's avatar
      Add a IANA timezone to country mapping · aacfed54
      Volker Krause authored
      This is largely unique, and should allow us to improve the result for the
      coordinate-based timezone lookup when having a country context.
      That was at least the initial motivation, however it looks like this might
      eventually allow us to build a coordinate -> country mapping as well,
      without needing an extra spatial index.
  25. 10 May, 2020 3 commits
    • 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.
    • 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).
    • Laurent Montel's avatar
  26. 23 Apr, 2020 3 commits
  27. 22 Apr, 2020 3 commits
  28. 21 Apr, 2020 2 commits