[PROJ] general use of proj_factors
Javier Jimenez Shaw
j1 at jimenezshaw.com
Thu Oct 24 23:49:59 PDT 2024
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.oberholtzer at gmail.com>
wrote:
> On Thu, Oct 24, 2024 at 5:42 PM Javier Jimenez Shaw <j1 at 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.oberholtzer at gmail.com> wrote:
> >>
> >> On Thu, Oct 24, 2024 at 2:36 PM Javier Jimenez Shaw <j1 at 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 at 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 at 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 at lists.osgeo.org
> >> >>> https://lists.osgeo.org/mailman/listinfo/proj
> >> >>
> >> >> _______________________________________________
> >> >> PROJ mailing list
> >> >> PROJ at lists.osgeo.org
> >> >> https://lists.osgeo.org/mailman/listinfo/proj
> >>
> >>
> >>
> >> --
> >> Roger Oberholtzer
>
>
>
> --
> Roger Oberholtzer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20241025/d6fcfe74/attachment.htm>
More information about the PROJ
mailing list