Fix slowness on proj_create_crs_to_crs() on WGS 84 <--> UTM conversions

[plumewind]

problem

When using proj-9.5.0, find very slow on proj_create_crs_to_crs().
My code like this:

  int zone = static_cast<int>((lon_rad * 180 / M_PI + 180) / 6) + 1;
  std::string latlon_src =
      "+proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs";
  std::string utm_dst =
      absl::StrCat("+proj=utm +zone=", zone, " +ellps=GRS80 +units=m +no_defs");

  PJ_CONTEXT *C = proj_context_create();
  PJ *pj_latlon =
      proj_create_crs_to_crs(C, latlon_src.c_str(), utm_dst.c_str(), NULL);
  if (0 == pj_latlon) {
    fprintf(stderr, "Failed to create transformation object.\n");
    return false;
  }

  PJ *norm = proj_normalize_for_visualization(C, pj_latlon);
  if (0 == norm) {
    fprintf(stderr, "Failed to normalize transformation object.\n");
    return false;
  }
  proj_destroy(pj_latlon);
  pj_latlon = norm;

  PJ_COORD a = proj_coord(lon_rad * RAD_TO_DEG, lat_rad * RAD_TO_DEG, 0, 0);
  PJ_COORD b = proj_trans(pj_latlon, PJ_FWD, a);
  utm_xy->x = b.xy.x;
  utm_xy->y = b.xy.y;

  proj_destroy(pj_latlon);
  proj_context_destroy(C); 

Problem description

When I was processing the conversion, I found that the process was very slow. Then, I counted the time taken for each process and found the following:

Expected Output

Normally, this process on proj_create_crs_to_crs() should be very fast, almost 0 milliseconds.

Environment Information

• PROJ version (proj-9.5.0)
• Operation System Information (ubuntu 20.04)

Installation method

mkdir -p build           
cd ./build              
cmake .. -DBUILD_SHARED_LIBS=ON -DBUILD_TESTING=OFF -DCMAKE_INSTALL_PREFIX=/opt 
 -DCMAKE_BUILD_TYPE=Release
make
sudo make install

[jjimenezshaw]

Have you tried adding +type=crs to both CRSs?

[rouault]

Have you tried adding +type=crs to both CRSs?

proj_create_crs_to_crs() automatically adds its

found that the process was very slow.

Well 16 ms is not so bad for something that involves looking in a database. In that particular case, we could perhaps avoid the database lookups given both CRS involve unknown datums, but haven't looked more closely.

The general advice is that you should keep the objet returned by proj_create_crs_to_crs() to transform many points, rather than recreating it each time

[plumewind]

First of all, thank you very much for your reply.

I understand everything you said, but my current requirement is a one-time conversion tool to convert the coordinates of several points, and the positions of the points are not regular, in other words, their zone numbers are random.

I used version 7.1.0 before and it was great to use. The code is as follows:

  projPJ pj_latlon;
  projPJ pj_utm;
  int zone = static_cast<int>((lon_rad * RAD_TO_DEG + 180) / 6) + 1;
  std::string latlon_src =
      "+proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs";
  std::string utm_dst =
      absl::StrCat("+proj=utm +zone=", zone, " +ellps=GRS80 +units=m +no_defs");
  if (!(pj_latlon = pj_init_plus(latlon_src.c_str()))) {
    return false;
  }
  if (!(pj_utm = pj_init_plus(utm_dst.c_str()))) {
    return false;
  }
  double longitude = lon_rad;
  double latitude = lat_rad;
  pj_transform(pj_latlon, pj_utm, 1, 1, &longitude, &latitude, nullptr);
  utm_xy->x = longitude;
  utm_xy->y = latitude;
  pj_free(pj_latlon);
  pj_free(pj_utm);

But now, after upgrading to 9.5.0, I find that the previous code cannot run, and I eventually realize that this time-consuming process is very troublesome. Can you improve it? Thank you.

[rouault]

their zone numbers are random.

they can not be that random. They must be between 1 and 60, so you could pre-compute 60 transform objects and re-use them

Can you improve it?

Cf #4320

[plumewind]

They must be between 1 and 60,

Haha, I definitely know, it must be within 1-60!
Thank you.

[plumewind]

Cf #4320

How can I pull the latest code for verification?

[plumewind]

pre-compute 60 transform objects and re-use them

Good idea, I can improve it later!