Add tilegrid 4326 #92

meilinger · 2019-11-12T21:19:34Z

This will need to be used in concert w/ a PR (# to be updated) against tegola when I complete the conflicts from the current rebase against v0.11.x

…rid in extent calculations

- Used for slippy tile operations

ear7h

Thank you for this pull request! We've been trying to find a good Tile <=> Projection relationship for a while now and this TileGrid concept is really good. I have few changes for convention and cleaning up the api. Thank you!

ear7h · 2019-11-26T04:54:25Z

slippy/tile_grid.go

+)
+
+// TileGrid contains the tile layout, including ability to get WGS84 coordinates for tile extents
+type TileGrid interface {


From my understanding the TileGrid is what defines the rules for the tiles and how they're placed. If this is correct, I think the following changes should be made:

the name should be changed to TileScheme which alludes to the rules which the tiles are created and laid out. "Grid" makes me thing of a structure which already exists (in memory); like a "dish" vs a "recipe"

the implementation should use the Tile type wherever possible. By doing this, the Tile and TileGrid types can be simplified and some functions moved to stand alone with func(TileGrid, Tile .... signatures. I'm thinking the new types and signatures would look like this:

type TileGrid interface { // returns the srid of the projection of this tiling scheme // the geom types from the other methods will be in this projection. SRID() int // this should return the (exclusive) maximum tile in this zoom. AKA: // Tile{z, MaxX+1, MaxY+1}. // it is exclusive so this function can be easily used for boundary checks Size(z uint) Tile // converts from a point (in the tile scheme's projection) and zoom to a tile. // ok will be false if the point is not valid in the projection FromNative(z uint, pt geom.Point) (t *Tile, ok bool) // Retuns the tile's upper left point. ok will be false if the tile is not valid. // <strike>one thing to note about implementing this is that you can compare tiles directly: // ok := tileScheme.Max(tile.Z) >= tile</strike> // second thing to note is that the ToNative(Tile) (pt geom.Point, ok bool) } // no need for the srid because f can be made a closure func RangeFamilyAt(TileGrid, Tile, f func(*Tile) error) error // Tile.ExtentXXXX aren't needed because of ToNative // NewTileLatLon aren't needed beacuse of FromNative

I believe that we'd still need a mechanism to support getting a tile's extent in both projected as well as WGS84 units to support downstream usage within Tegola. Part of the reasoning for separating tiling logic out to support equirectangular tile schemes is in support of tile rendering as "4326" and a non-square tile grid. But, again, I very well could be missing some of the vision for these changes. I'd love to chat further so that I'm on the same page!

I was thinking that the conversion from one coordinate system to another should be decoupled from slippy (it was not before, but it is something we were looking to change). The implementer of Grid works only with its native units and then the calling code can use the proj package to convert to WGS84 or other projection systems.

Gotcha. Makes sense.

@ear7h re: you can compare tiles directly, I didn't realize that structs in golang offered an ordering mechanism (or operator overloading) but am having trouble a mechanism to support this construct. Is there something I'm missing or misunderstanding?

@meilinger My mistake, that doesn't work 😬 They can be compared for equality but not ordering.

ear7h · 2019-11-26T06:05:11Z

slippy/projections.go

-// Tile2WebY returns the side of the tile in the +y side
-func Tile2WebY(zoom uint, n uint) float64 {
+// Tile2WebY returns the side of the tile in the +y side in webmercator
+func Tile2WebY(zoom uint, n uint, srid uint) float64 {


The extra arg isn't really necessary here. If it's being used elsewhere to satisfy func (uint, uint, uint) float64 signature, a closure should be made there. Since there there isn't a type requirement in this package it shouldn't be forced here.

ear7h · 2019-11-26T06:05:24Z

slippy/projections.go

-// Tile2WebX returns the side of the tile in the -x side
-func Tile2WebX(zoom uint, n uint) float64 {
+// Tile2WebX returns the side of the tile in the -x side in webmercator
+func Tile2WebX(zoom uint, n uint, srid uint) float64 {


The extra arg isn't really necessary here. If it's being used elsewhere to satisfy func (uint, uint, uint) float64 signature, a closure should be made there. Since there there isn't a type requirement in this package it shouldn't be forced here.

ear7h · 2019-11-26T06:06:49Z

slippy/projections.go

 // TODO (@ear7h): perhaps rethink this
-func Pixels2Webs(zoom uint, pixels uint) float64 {
-	return WebMercatorMax * 2 / math.Exp2(float64(zoom)) * float64(pixels) / MvtTileDim
+func PixelsToProjectedUnits(zoom uint, pixels uint, srid uint) float64 {


This could be renamed ~~FromPixels~~ Pixels2Native and have a func (TileGrid, zoom, pixels uint) float signature

ear7h · 2019-11-27T20:49:49Z

slippy/tile_grid.go

+	YIndex2Lat(zoom, y uint) (lat float64)
+}
+
+func GetGrid(srid uint) TileGrid {


For convention, this function should be renamed NewGrid. Also, as a clarification, are there external limitations (other programs, a spec, convention etc.) which prevent the usage of square tiles with 4326 projection?

I believe that, from my experience, when someone mentions "4326" as the projection (which it is not), they are typically referring to equirectangular projection using lat/lon and WGS84 geoid upon a 2x1 tile ratio scheme (using square tiles, but 2x1 tile extent). But that is completely notional, not part of a spec and my experience is only a single data-point in usages.

I think I understand what's going on bit better now, thank you for the explanation. I always get confused with srid, projections, and datums. From what I've found after a brief search it seem like some programs expect the behavior you describe. So, I think the functionality here is good.

I hear ya, I still get confused as to difference of them as well.

ear7h · 2019-11-27T20:54:02Z

slippy/tile_grid.go

+}
+
+type grid struct {
+	tileExtentRatio float64


Could you document what this ratio is? x/y or y/x

meilinger · 2019-11-27T20:57:18Z

Awesome, @ear7h! Thanks for the comprehensive feedback! Will address momentarily.

ear7h · 2019-12-03T01:02:20Z

@meilinger Hey, if you haven't started working on this, I'd like to take over and get it finished up. That way, we'll have more time to work through the PRs sitting in tegola 😅

meilinger · 2019-12-03T01:05:11Z

Sounds good, I got a little way through but feel free to knock it out.

…

On Mon, Dec 2, 2019, 7:02 PM Julio ***@***.***> wrote: @meilinger <https://github.com/meilinger> Hey, if you haven't started working on this, I'd like to take over and get it finished up. That way, we'll have more time to work through the PRs sitting in tegola 😅 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#92?email_source=notifications&email_token=AABQEK2F5PQSWK3PFNPKHZDQWWVZ3A5CNFSM4JMJGVB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFXWWIY#issuecomment-560950051>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABQEK3HZYUNSW6OY5FHT2DQWWVZ3ANCNFSM4JMJGVBQ> .

ear7h · 2019-12-03T01:12:20Z

👍

* first cut of tile grid * slippy tiles can more elegantly handle multiple projection systems

meilinger added 5 commits November 12, 2019 11:18

Add in NativeExtent, add support for specifying the tile's rendered s…

cd9dd96

…rid in extent calculations

Create TileGrid

a873066

- Used for slippy tile operations

TileGrid. cleanup

73f91f4

Update to include srid in RangeFamilyAt and TileMinMaxer

2f49eac

Updated test to use new Extent3857 signature

f9bc00a

ear7h requested changes Nov 27, 2019

View reviewed changes

ear7h changed the base branch from master to tile-grid December 3, 2019 05:56

ear7h merged commit 61c45e3 into go-spatial:tile-grid Dec 3, 2019

ear7h pushed a commit that referenced this pull request Dec 13, 2019

Add tilegrid 4326 (#92)

1e39e22

* first cut of tile grid * slippy tiles can more elegantly handle multiple projection systems

ear7h pushed a commit that referenced this pull request Jan 20, 2020

Add tilegrid 4326 (#92)

9075c1d

* first cut of tile grid * slippy tiles can more elegantly handle multiple projection systems

gdey pushed a commit that referenced this pull request Jan 22, 2020

Add tilegrid 4326 (#92)

c15ae9a

* first cut of tile grid * slippy tiles can more elegantly handle multiple projection systems

Uh oh!

Add tilegrid 4326 #92

Add tilegrid 4326 #92

Uh oh!

Conversation

meilinger commented Nov 12, 2019

Uh oh!

ear7h left a comment

Choose a reason for hiding this comment

Uh oh!

ear7h Nov 26, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ear7h Nov 26, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

meilinger Nov 29, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

meilinger commented Nov 27, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ear7h commented Dec 3, 2019

Uh oh!

meilinger commented Dec 3, 2019 via email

Uh oh!

ear7h commented Dec 3, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

ear7h Nov 26, 2019 •

edited

Loading

ear7h Nov 26, 2019 •

edited

Loading

meilinger Nov 29, 2019 •

edited

Loading

meilinger commented Nov 27, 2019 •

edited

Loading