-
-
Notifications
You must be signed in to change notification settings - Fork 193
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support a proj query parameter for rendering in various projections #267
Comments
@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 OpenLayers supports any projection essentially. |
@ARolek - what would you like the proj API to support, to give you this use case? Do you want proj strings, or something else? |
@singram7 also curious your thoughts here. |
@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 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
} |
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..? |
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 ***@***.*** > 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
<#267 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABbwW7uzL5MKUW32nrYGE59er8ceKakTks5toPkdgaJpZM4RqBBE>
.
|
@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 Again, I don't know if this is possible based on my limited knowledge around proj4 strings, but this is the high level idea. |
the |
Would be great to have custom projection for vector tiles output. |
I would like to add projection 25833. Where should I start to look? |
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:
|
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'; |
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.
The text was updated successfully, but these errors were encountered: