0

I have a segmented path/route on a map, and my software needs to request imagery from a server to completely cover the route. Image requests to the server can only be for rectangular regions (aligned with the cardinal directions). Simply requesting a single, big image for the path's bounding rectangle often results in downloading an extremely large image, especially for long paths. It would be better to break it up into several smaller image requests, especially for long, winding routes.

But I'm having difficulty coming up with a good algorithm for this. Does anyone know of a relevant algorithm, or a white paper or something that might be useful? Suggestions? This image explains the problem better than I can in words:

This image explains the problem and challenges

WeatherLightning
  • 1
  • 1

2 Answers2

0

Are you confident that you have all the details? In the systems with which I am familiar, the area for which information is available is tiled and you can request only tiles, and not arbitrary geographical regions. Different sizes of tiles are available, but tiles covering smaller areas provide more detail, so the choice of tile size does not depend on the area you are trying to cover, but on the level of detail you want to display. If the underlying system providing the data is also tile-based you may make its life easier by requesting areas that are exact tiles, although this won't optimise the communications traffic. This also simplifies the choice of tiles - you decide how much detail you need, and then request all the tiles required to cover the area you want to display.

Going back to the problem you have actually asked, consider a single straight line with a constant slope. If you cut the map into vertical strips with a given width, then each strip contains a rectangle that you must provide, so that you can always show an area of 100 miles above and below the line. So given a rectangle width, you can work out the required rectangle height. Given a rectangle width you can also work out how many rectangles you need, so you have the two things that determine the cost - the number of different rectangles and the total area of the rectangles. Typically the cost of transferring a rectangle is roughly a constant cost per rectangle and a variable cost that grows with the area of the rectangle. One way to assess these costs would be to measure the amount of data required to transfer rectangles of different sizes and fit a straight line to it. Given a way of calculating the costs for different widths of rectangle, I would use a one-dimensional numerical minimisation routine to work out the most efficient width. One example of this is https://en.wikipedia.org/wiki/Golden_section_search.

mcdowella
  • 19,301
  • 2
  • 19
  • 25
  • Yeah, our system does allow requesting arbitrary geographic regions. In the future we may look at optimizing based on underlying tiles. My current plan is basically what you suggest, fixed tile width, calculate the necessary height(s) in each vertical strip. I'm thinking about how to recognize when the heights in 2 adjacent strips are close enough to just merge them, eg, a long, straight horizontal path. Would also be good to think about using the turnpoints/waypoints as good places to split. Thanks for the detailed answer! – WeatherLightning Jul 01 '16 at 05:14
0

Your problems is lacking a few details so I'm going to assume that:

  1. This goes on a screen of some form which has a width and height, so the bare minimum required to the area covered by the screen when moved along the path.
  2. The number of requests doesn't matter as much as the amount of data transmitted.

So with that what you can do is a divide and conquer approach. You start with the enclosing rectangle. At each step you figure out if:

  1. The rectangle is within the region of interest for one segment. That is the rectangle is only contains pixels that you want to download.
  2. The rectangle is completely outside the region of interest.
  3. There's some overlap with regions of interest.
  4. There's some overlap but the rectangle is sufficiently small.

If the rectangle is completely in or out then it's easy, request the rectangle if it is in ignore if it is out. If there's some overlap but the rectangle is small (case 4) you can just download it to ease on the computation. You can go down to the pixel but that's probably overkill.

The tricky case is if there's some overlap and the rectangle is large. In this case you divide the rectangle into 4 smaller ones (half along each side) and call recursively for the 4 smaller ones. One tiny optimization: If the algorithm decides to fetch all 4 smaller ones entirely, you should fetch the larger one instead of the 4 small ones.

To decide on the inclusion overlap, you can take each piece of the path, and for each you take the view rectangle place it at each end, link the corresponding corners and take the convex hull. Then compute the intersection/overlap of the convex hull with the rectangle you are testing.

While this seems a bit complicated it should cover well a bunch of corner cases (like very small path segments, or self intersecting path).

Sorin
  • 11,863
  • 22
  • 26