1. 03 Jan, 2021 1 commit
  2. 02 Jan, 2021 1 commit
  3. 10 Dec, 2020 1 commit
  4. 27 Nov, 2020 1 commit
  5. 18 Nov, 2020 1 commit
  6. 15 Nov, 2020 1 commit
  7. 14 Nov, 2020 2 commits
  8. 11 Nov, 2020 1 commit
  9. 07 Nov, 2020 1 commit
  10. 05 Nov, 2020 2 commits
  11. 03 Nov, 2020 7 commits
  12. 02 Nov, 2020 5 commits
  13. 01 Nov, 2020 1 commit
  14. 30 Oct, 2020 1 commit
  15. 29 Oct, 2020 1 commit
  16. 28 Oct, 2020 2 commits
  17. 27 Oct, 2020 1 commit
  18. 23 Oct, 2020 1 commit
  19. 12 Oct, 2020 1 commit
    • Volker Krause's avatar
      Forward-declare OsmType · a8943e57
      Volker Krause authored
      This avoids including a non-installed header file here, which broke the
      build for external users.
      a8943e57
  20. 11 Oct, 2020 3 commits
    • Volker Krause's avatar
      Don't discard non-visual multi-polygon parts with tags during OSM loading · 9f697227
      Volker Krause authored
      Those are extremely rare, and obviously have no visual impact in Marble,
      but they do contain valuable information for other users of the vector
      tiles.
      
      An example are railway=platform_edge segments of railway platforms (and
      that's actually the only case affected by this I have found so far), and
      that's about 1.5k elements for all of Germany, so not an amount that would
      matter in the big picture.
      9f697227
    • Volker Krause's avatar
      Fix string length computation for O5M encoding · 507171b5
      Volker Krause authored
      We need to consider the UTF-8 encoded string length here, which can differ
      from the QString length previously used. In most cases the difference isn't
      relevant, but I have encountered two tiles so far where those values not
      only differed, but ended up on either side of the 250 character limit here.
      If that happens the string table in the o5m decoder when reading this ends
      up in an inconsistent state, and produces spectacularly messed up tags.
      
      While at it, also sharpen the asserts here, violating either of those would
      produce invalid o5m output.
      507171b5
    • Volker Krause's avatar
      Avoid losing the OSM relation member type information · 9dd870a6
      Volker Krause authored
      There seems to be the assumption in a number of places here that a single
      64bit number is enough to identify any OSM element. This however isn't
      entirely correct, as OSM nodes, ways and relations use separate identifier
      spaces, so we either need to infer the type from context or explicitly
      carry it along next to the number. This wasn't done for non-geometry
      relation members however, resulting in all member types ending up as "way"
      when serialized back to o5m, which quite thoroughly corrupts those
      relations.
      
      This change does the bare minimum to fix this specific issue, API not
      relevant for this is adjusted to keep the old broken behavior.
      
      With relation member types preserved we however hit a subsequent problem
      in the o5m encoder, which needs to track differential id encoding state
      separately per type.
      9dd870a6
  21. 05 Oct, 2020 2 commits
  22. 22 Sep, 2020 1 commit
    • Volker Krause's avatar
      Don't discard any OSM nodes with tags during loading · 5ded04e1
      Volker Krause authored
      This affects a very small amount of nodes that are not currently rendered
      by Marble (e.g. various types of free-standing ticket vending machines).
      With this change those are also included in the generated o5m tiles, which
      matters for other users than Marble (and presumably Marble would want to
      show those properly eventually too).
      
      This also require a minor change to Marble's style selection, as unknown
      nodes were shown with the default style (a yellow dot) so far, which is
      undesired I assume (but made it very easy to verify this is only a small
      amount in total).
      5ded04e1
  23. 19 Sep, 2020 1 commit
    • Volker Krause's avatar
      Improve check for closed polygons · bfd57531
      Volker Krause authored
      This was failing on highway=* areas so far, treating them as (open) ways
      and badly messing up clipping as a result of that. This is visible in the
      old tiles as well, and affects both Marble's rendering as well as geometry
      reassembly.
      bfd57531
  24. 17 Sep, 2020 1 commit
    • Volker Krause's avatar
      Rewrite tracking of OSM data across clipping · 75fe1f3d
      Volker Krause authored
      The previous approach put coordinate pointers into the point structures of
      the clipper lib. This worked in most cases, but as there are no guarantees
      on point references remaining valid, the clipper lib ended up swapping
      values of points in some cases, breaking our coordinate references and
      subsequently losing the attached OSM data. While this is usually not a
      problem for a random node, it could also happen on the closing node of a
      polygon, causing it to no longer be closed and confusing the hell out of
      the geometry reassembly code.
      
      The new approach tracks this outside of the clipper lib with a map on the
      integer coordinates (and thus avoiding floating point number comparison
      issues). This also allows us to roll back a bunch of Marble-specific
      changes to the clipper code.
      75fe1f3d