TileAreaPolygonalBuilder could implements min and max precision

[tspoke]

For now the algorithm only check for one precision. It could be interesting to handle differents precisions and merge smaller OLC into bigger if possible.

Right now I only have 2 differents implementations in mind :

• Scanline each precisions EXCLUSIVE (begin with higher scan and ignore with resultset the next OLC in the smaller pass).
• Scanline for smallest precision and determine mergeable groups after.

TileAreaPolygonalBuilder.setPrecision(/* ANY */) => will set min/max to same precision

TileAreaPolygonalBuilder.setMinPrecision(/* ANY */);
TileAreaPolygonalBuilder.setMaxPrecision(/* ANY */);

[bocops]

I thought about doing the merge part via a different TileArea implementation. Currently, SimpleTileArea just collects all individual tiles that are added to it and does not attempt any cleanup.

If the implementation there kept track of how many tiles with the same prefix exist, it could merge them into a larger unit once they are complete (=all 20x20 smaller tiles exist), or even based on some threshold value (merge if >95% of smaller tiles exist).

This would work well with your suggestion, but also make the merge functionality reusable for other contexts.

[bocops]

In commit 554d0f3

• TileAreaPolygonalBuilder.setPrecision() replaces .setTileSize() - the suggested new name really makes more sense.
• A new TileArea implementation, MergingTileArea, is used by the builder to eventually return a list of tiles where smaller ones are merged into bigger ones as far as possible. This also speeds up creating larger polygonal areas by an order of magnitude (probably more for even bigger areas than tested).

I wonder about the suggestions of being able to set a min/max precision. I think that the maximum precision (the smallest tile size we produce) is the same as the one already set by .setPrecision().

If we're setting a minPrecision (the largest tile size we eventually merge to), this value could be used to prevent MergingTileArea to merge beyond some arbitrary tile size. If tiles could be merged (because all subtiles exist), is that something that we'd ever want to do?

[tspoke]

I strongly agree about setup the maxPrecision with the setPrecision() value.

I think we need the minPrecision to limit the merge; For instance, I'm thinking of this feature in a software I'm developing (I need to be sure the minPrecision is the same for every node at the root of the graph).

[bocops]

OK, this is now added in b75c3e9. :)

I'm not sure though if this does exactly what you'd like it to do. Imagine a "square" region that spans 0° - 1.5° degree latitude and longitude. The part spanning 0°-1.0° will be merged into a single tile with a 4-character tile address (or, in terms of plus codes, something like XXXX0000+), while the rest is not a full 4-char area and will instead remain a number of 6-char areas (or XXXXXX00+). Is that OK for you?

[tspoke]

I'm currently porting all your code/test in typescript. As soon as I finish this port I will fully test the implementation and give you a feedback about it.

https://github.com/tspoke/open-geotiling-typescript

For my use-case, I'm building a graph to optimize "in-zone for delivery", like :

const zones = {
  "YYYY0000+" : {
    "stores": ["a", "b"],
    "zones": {
      "YYYYYY00+": {
        "stores": ["e"],
        "YYYYYYYY+": { "stores": ["f"] }
      },
      "YYYYXX00+": {
        "stores": ["c"],
        "YYYYXXYY+": { "stores": ["f"] }
      }
    }
  }
};

I want to say : I'm currently at code YYYYYY00+, which stores delivers here ? And get easily the list of stores (a, b and e) without looping on their area each time.
That's why I was looking for an algorithm to merge tiles in bigger one to reduce memory usage (db).