Imforgot to saym this. The problem I have to solve is that I need to be able to export also to other projections. For our indoor navigation and accurate site maps we have to use a proper projection. Thus my idea to index WGS84 datum, and enble to index oberlappings efficiently. When this is solved it should be possible to load WGS84 data cells that overlap a world area for a given projection (using the bbox from input, loading overlapping MODIS cells) and cut the export at the bounding sites later on.
Ben Von meinem iPad gesendet > Am 06.01.2016 um 13:41 schrieb Andrew Byrd <[email protected]>: > > >> On 06 Jan 2016, at 13:13, Andrew Byrd <[email protected]> wrote: >> Obviously in the long term we’ll want to improve the index to handle these >> cases. Both of these limitations should be straightforward to overcome. To >> index large polygons as areas and you’d either need some kind of multi-level >> index (rectangle tree or “pyramids") or just accept rasterizing area >> polygons into all the index cells they overlap (a polygon’s ID appearing >> repeatedly, in every tile it overlaps). > > I should elaborate: > > Using a predefined grid is practical because you don’t need to store the > bounds of the index nodes (they’re regular tiles, so their bounding boxes are > implicit in the grid definition). You can determine which index cell any > element is in by just chopping low-order bits off its projected coordinates > to match the index’s constant zoom level. > > If you’re rendering map tiles, there’s also the advantage of a 1:1 > correspondance between one spatial index node and one output map tile at or > above the index’s zoom level, and a simple one-to-many relationship below > that zoom level. This is also practical for exporting rectangular PBF regions. > > If you want to index objects physically larger than a tile in the index or > reflect the fact that objects span tiles, you could repeat the identifier of > that object in every tile it touches (what I referred to as rasterizing the > geometry), but this approach leads to a lot of repetition of identifiers and > de-duplication of identifiers when you query the index. > > An alternative approach is a hierarchical index, where each index node is > entirely physically contained within a higher-level node. Conveniently the > web Mercator map tile system defines a perfectly aligned hierarchy of squares > via its zoom levels: it is a quad tree > (https://en.wikipedia.org/wiki/Quadtree). You simply index each object at the > highest zoom level that still contains the object entirely within one tile, > and when you do a query operation from the index, you can easily traverse up > the zoom levels without maintaining pointers between them (you can find the > coordinates of the next higher tile by just chopping off low order bits). > > There are of course many ways to implement spatial indexes, but considering > that we’re working with data that often gets rendered or exported in > tile-sized chunks, this approach seemed well-suited to me. > > I’d of course welcome any insight or suggestions that might improve our > implementation. > > -Andrew _______________________________________________ dev mailing list [email protected] https://lists.openstreetmap.org/listinfo/dev
