About proj_create_crs_to_crs giving wrong results, I do not know. Maybe an axis order problem? Providing a transformation instead of a CRS is obviously faster. Less work for the algorithm to obtain the transformation from the CRS (creating temporary structures, etc). I just mentioned the option to provide a CRS for completeness, not expecting that it is the fastest solution. As Thomas mentioned, internally the algorithm is using a projection transformation.
Cheers Javier On Fri, 25 Oct 2024 at 08:28, Roger Oberholtzer <roger.oberholt...@gmail.com> wrote: > 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
