Support a proj query parameter for rendering in various projections

[singram7]

Vector Tiles have no projection, thus any cylindrical projection on the WGS84 Datum can be rendered into Vector Tiles in meters. The default is currently web-mercator (3857), but 3395 (Elliptical Mercator) could be supported.

[ARolek]

@singram7 I agree. @gdey and I talked through this today and we're going to add this to the v0.7.0 release. We want to implement more robust projection handling and will use 3395 as second projection system we will support.

Your idea with using a query string is interesting. Though this is completely possible I need to think through some of the caching ramifications. I'm initially inclined to have the map projection be configurable by the user rather than the requester, though I could see the use case for the later.

Thanks for the suggestion. The timing lines up perfectly with the development discussions we're having on this end.

[JivanAmara]

@singram7, @ARolek, I understand mapbox only supports 3857. What other map clients beyond mapbox are being used w/ tegola making additional projections requested from the client side useful?

[jj0hns0n]

@JivanAmara OpenLayers supports any projection essentially.

[mpgerlek]

@ARolek - what would you like the proj API to support, to give you this use case? Do you want proj strings, or something else?

[jj0hns0n]

@singram7 also curious your thoughts here.

[ARolek]

@mpgerlek from an user's perspective I think it would be ideal to use SRID values. This could then be leveraged in the tegola config, query strings for tile requests, and it's also the value we work with when determining if a geometry from a data provider needs re-projection.

For the proj project have you considered generating Go code from a list of projection strings? In an ideal world an interface could be established that all the projections could leverage and tegola would be able to call a method like (rough sketch):

var p []float64{32.715738,-117.161084}

// proj.Project(from, to uint, point ...float64) ([]float64, error)
p, err := proj.Project(4326, 3857, p...)
if err != nil{
  // handle err
}

[mpgerlek]

Do we have a means to generate the proj string from an arbitrary SRID? Or are you thinking about just hardcoding in support for a handful of well-known epsg codes?

I'm not sure what you mean by "generate code" -- are you thinking about generating the actual AST on the fly can then calling into it, or..?

[singram7]

NGA would like to display data in 3395 specifically, but they have the means and resources to author their own projection code. In fact, they prefer to use an in-house projection library. Some support for interfaces would suffice for NGA uses if they could author their own custom code for specific projections. I believe their issue was the hard-coded nature of Tegola's output engine.

-Steve

PS. I am no longer involved in that NGA project as I have moved to the commercial satellite division of my company (Spaceflight Industries, Blacksky GeoSpatial)

On Fri, Apr 13, 2018 at 3:14 PM, Michael P. Gerlek <notifications@github.com

wrote:

Do we have a means to generate the proj string from an arbitrary SRID? Or are you thinking about just hardcoding in support for a handful of well-known epsg codes?

I'm not sure what you mean by "generate code" -- are you thinking about generating the actual AST on the fly can then calling into it, or..?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/go-spatial/tegola/issues/267#issuecomment-381235556, or mute the thread https://github.com/notifications/unsubscribe-auth/ABbwW7uzL5MKUW32nrYGE59er8ceKakTks5toPkdgaJpZM4RqBBE .

[ARolek]

@mpgerlek I was thinking more about having the SRID "hardcoded". Another way to think about this is using a registration type system, like Go does with the image package. We also take this approach with data providers and cache backends in tegola. This would also allow for @singram7 to to register a custom projection code (though it would require a custom build of tegola).

Re: generating code. I'm more referring to a way to automate parsing the proj4 codes and generating the Go code which would adhere to a common interface. I have not worked too much with proj4 strings so I'm not quite sure if this is possible. Ideally the proj package would have a list of ESPG codes and their respective proj4 strings, which we could then use to generate Go code that would make up much of the proj package. Want to add a new ESPG code? Add it ands the pro4 string to the list and regenerate.

Again, I don't know if this is possible based on my limited knowledge around proj4 strings, but this is the high level idea.

[mpgerlek]

the proj4go part of this thread has been moved to https://github.com/go-spatial/proj4go/issues/3

[fgravin]

Would be great to have custom projection for vector tiles output. +1

[ARolek]

@fgravin we're going to be bringing in the proj package into tegola during our v0.8.0 release cycle. The package currently supports 3395, 4396 and 3857 projections. If you would like additional ones supported you can open issues there, or send in PRs ;-).

[RobertSasak]

I would like to add projection 25833. Where should I start to look?

[gdey]

@RobertSasak

Currently, the projection system in Tegola only supports transforming data in a different projection to webmercator. At current the render system only outputs to webmercator. The proj project will help us to remove this limitation.

Well it depends on which direction you want to go:

1) the quick way would be to adapt the current system, that will be thrown away.

• Add a new package that can do the conversion.
  • Currently for webmercator it's in the math/webmercator package.
• Add a new constants to tegola/projections.go
• Add a case to the toWebMercator and fromWebMercator.

2) The long way, which would be to add it to the proj package, and then integrate that into tegola. This is the long-term direction. This will probably take quite some time, and I have not had the time to look over the proj package and code review it. This is my plan after the refactor of the math and geom package which is what I'm doing now.

[RobertSasak]

Thank you for a quick reply. As I am only playing with data I found the easiest to convert all data to correct projection directly in DB.

Below is my sql script. First I select all tables that contain myColumn and then I concat ALTER command.

select 
'ALTER TABLE ' || table_schema || '.'|| table_name || '
 ALTER COLUMN myColumn TYPE geometry(Geometry,3857) 
  USING ST_Transform(myColumn,3857);
'
 FROM information_schema.columns WHERE column_name = 'myColumn';