The last versions also accept a projected CRS, extracting the projection from it.
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 >
_______________________________________________ PROJ mailing list PROJ@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/proj
