On Thu, Oct 24, 2024 at 5:42 PM Javier Jimenez Shaw <j...@jimenezshaw.com> wrote: > > https://proj.org/en/9.5/development/reference/functions.html#c.proj_factors > You just provide the projected CRS, just created from the EPSG code. It > converts it internally into the projection over its geographic.
If I use something defined with proj_create_crs_to_crs I get incorrect values for the meridian convergence. If I provide an EPSG code to proj_create and use that, I get the correct values, but it takes an extremely long time for each calculation. As I wrote, projections that should take 15 minutes take 15 hours. The thing that seems to work best is proj_create with a proj string that does not contain +type=crs. I am wondering if this is all expected behavior. > > On Thu, 24 Oct 2024 at 15:19, Roger Oberholtzer <roger.oberholt...@gmail.com> > wrote: >> >> On Thu, Oct 24, 2024 at 2:36 PM Javier Jimenez Shaw <j...@jimenezshaw.com> >> wrote: >> > >> > The last versions also accept a projected CRS, extracting the projection >> > from it. >> >> I am using 9.4.0. Do you mean that I should be able to use this? >> >> proj_normalize_for_visualization(0, >> proj_create_crs_to_crs( 0, >> "EPSG:4326", >> "EPSG:3006", >> 0)))) >> >> If that's what you mean, it seems that the convergence values are not >> as expected. Or do you mean something else? >> >> > >> > On Thu, 24 Oct 2024, 14:27 Thomas Knudsen via PROJ, <proj@lists.osgeo.org> >> > wrote: >> >> >> >> Roger, >> >> >> >> The "factors" elements refer to a projection, not to a CRS >> >> (the CRS includes reference frame information), and not >> >> to a transformation (which describes a path between two >> >> different CRS). >> >> >> >> So you should only call proj_factors on a PJ object obtained >> >> from a plain classic proj(ection) string, i.e: >> >> >> >> p = proj_create(0, "proj=utm zone=33 ellps=GRS80"); >> >> >> >> >> >> Den tors. 24. okt. 2024 kl. 14.11 skrev Roger Oberholtzer via PROJ >> >> <proj@lists.osgeo.org>: >> >>> >> >>> Hi all, >> >>> >> >>> I have been using proj_factors in a couple CRS to get the >> >>> median_convergence value. I need this when rotating a point that has >> >>> been projected into the CRS. >> >>> >> >>> In my usual setup, I define something like the following (WGS84 (from >> >>> a GPS receiver) to Sweref99): >> >>> >> >>> proj_normalize_for_visualization(0, >> >>> proj_create_crs_to_crs( 0, >> >>> >> >>> "EPSG:4326", >> >>> >> >>> "EPSG:3006", >> >>> 0)))) >> >>> return(ISERROR); >> >>> >> >>> This works fine. I get the points I expect. But as I will need to >> >>> rotate that point using data from the GPS (heading is true north), I >> >>> need to know how that differs from the projected point's north. So I >> >>> use proj_factors. As it turns out, I cannot use the definition from >> >>> above to do this. The median_convergence value is wrong. So what I >> >>> have been doing (for EPSG:3006 - it is CRS-specific) is defining >> >>> something like this: >> >>> >> >>> proj_create(0, "+proj=utm +zone=33 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 >> >>> +units=m +no_defs"); >> >>> >> >>> You will note that this is the implementation of EPSG:3006, but >> >>> without +type=crs. Why without that parameter? Time. When including >> >>> it, the proj_factors call takes around 60 times longer. This is >> >>> extremely significant when generating, say, point clouds with hundreds >> >>> of million points. A processing time of 15 minutes becomes 15 hours. >> >>> The values provided are exactly the same. But one takes significantly >> >>> longer to provide them. >> >>> >> >>> I see this effect in more than EPSG:3006. For example EPSG:5677. I >> >>> suspect that it is generally the case. >> >>> >> >>> What I would like to do is something like this: >> >>> >> >>> proj_normalize_for_visualization(0, >> >>> proj_create_crs_to_crs( 0, >> >>> >> >>> "EPSG:4326", >> >>> >> >>> "EPSG:3006", >> >>> 0)))) >> >>> return(ISERROR); >> >>> >> >>> proj_create(0, "EPSG:3006"); >> >>> >> >>> >> >>> Where the first is used to project the point, and the second is used >> >>> to call proj_factors for that point. >> >>> >> >>> This would allow a general solution, which is what I am after. So I >> >>> either need to call something other than proj_create, or I need to see >> >>> how to remove +type=crs in this context. >> >>> >> >>> Does this make sense? >> >>> >> >>> -- >> >>> Roger Oberholtzer >> >>> _______________________________________________ >> >>> PROJ mailing list >> >>> PROJ@lists.osgeo.org >> >>> https://lists.osgeo.org/mailman/listinfo/proj >> >> >> >> _______________________________________________ >> >> PROJ mailing list >> >> PROJ@lists.osgeo.org >> >> https://lists.osgeo.org/mailman/listinfo/proj >> >> >> >> -- >> Roger Oberholtzer -- Roger Oberholtzer _______________________________________________ PROJ mailing list PROJ@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/proj
