Alternative works with proj9

[proj4tcl]

I have devised a tiny example which works with the current proj. It's a long way from being cpan ready but somebody may find some use for it. It's sufficient to run the first example on https://proj.org/development/quickstart.html, see examples/demo which should be self explanatory.

It uses Inline::C and it should be quite easy to add more functions as needed.

See https://github.com/proj4tcl/proj4perl

Noone ever expressed any interest in my proj4tcl. This is a similar interface :-)

[markov2]

A problem is that the "proj" project was extremely stable in version 4 of its library interface, and after that has seen rapid and seriously breaking changes (for the good). I studied it, and saw no way to improve the Proj4.pm module and all its related software: a full rewrite of everything is necessary. With that: I have currently no use for projections at all and lack time.

I think proj4* in the name of a project which supports proj9 is very confusing. I would suggest some extra care. Maybe something like:

my $proj = Geo::Proj9->new;

Not all Linux distributions moved between versions at the same time. You need separate Geo::Proj8, Geo::Proj7 releases. Be prepared for a partially incompatible Geo::Proj10. (Maybe, interface change frequency is down now)

[proj4tcl]

Perl is completely lacking a proj interface. Look at https://proj.org//development/bindings.html . Most of them are awful or outdated. Mine parallels the c interface and has done since about proj7 when I did my first modern tcl interface. It just needs someone who knows more perl than I do to tidy it up. Check it out.

[pdean]

now works on windows

[pdean]

proj4 is meant to be read as "proj for" that needs to be put to rest.

[johannessen]

Perl is completely lacking a proj interface. Look at https://proj.org//development/bindings.html

“Completely lacking” may be a slight exaggeration. Geo::LibProj::FFI does exist.

But yes, adding a pointer to the list of language bindings at proj.org seems like a good idea.

[pdean]

Yes you are correct there is that one. But I don't need all that threading, areas lists etc for what I do at work. I wanted something simpler eg what you can do with cct on the command line. I have the beginnings of something if you're interested. Using Inline::C it would be quite trivial to add a lot of that stuff if needed. I'm envisaging various modules under Geo::Proj namespace to take care of different subsets of proj functionality. I've called mine CCT. Perhaps I might do a Geod that does what geod does etc

My trans function just takes a reference to an array. You can give it 2d if you're working horizontally, 3d if vertically and I hope I never have to deal with kinematic coordinate systems in 4d but it could handle that too.

I've put it at https://github.com/pdean/geo-proj-cct I've done all I want to do to it at the moment and am moving on. There's an example of use at https://github.com/pdean/geo-proj-cct/tree/main/examples/testmga

And it had to work on windows easily. Just need a QGIS install and strawberry perl with Inline::C and aliased to save typing.

[johannessen]

For what it’s worth, threading contexts and areas are optional in PROJ. You can use them, but you don’t have to.

For a simpler Perl API close to the PROJ command line apps, see Geo::LibProj::cs2cs, which is also mentioned in the Geo::LibProj::FFI docs.

You have a point on Windows support though. I suspect both of my modules work fine on Cygwin, but there are likely problems on Strawberry. I don’t do Windows myself, but patches are welcome.

---

Regarding naming:

Should you decide to release your module to CPAN, I’m not sure Geo::Proj::CCT is a great choice, at least not in its present state. Your module isn’t compatible with Geo::Point/Geo::Proj, so anything in the Geo::Proj namespace may easily confuse people. ~Additionally, your module currently doesn’t seem to offer pipelines in the way cct does? In that case, CCT might not be appropriate as part of the name.~

That said, I’m not sure I have a better suggestion. Perhaps Geo::LibProj::Transform, something like that?

[markov2]

Arne, I did not know that your module was in such an excellent shape. I will probably deprecate Geo::Proj4 explicitly, in favor of yours. I did not expect anyone to use Geo::Point etc outside ::Proj4, but apparently I should keep them alive. Or you can take them from me.

I also think that Geo::Proj::CCT is a bad name. On CPAN, you should always ask the user of a second-level name (the module Geo::Proj) whether he/she agrees with using a subspace name. That's where these 'X' names come from... like MojoX. In this case, Geo::ProjX::CCT could have been picked without debate.

With debate: all my modules strive to 100% implementations... that's why I could not move from Geo::Proj4 to Geo::Proj[5-9] easily: I did not see any chance to bring the interface changes back into uniformity, supporting 100% of the features of the newer libraries. Without commitment to implement 100%, Geo::Proj::CCT does not contribute enough, I think.

[pdean]

Well it's not on CPAN, I've just offered some ideas for a way forward. I don't want to get behind a FFI solution though when it's possible to do a native solution.

[pdean]

And regarding the comment about pipelines, they are correct. Just run it, it works. I've been using a similar module I wrote for tcl for years.

[johannessen]

Well, apparently one thing the module that @proj4tcl and @pdean have been developing together (?) brings to the table is improved Windows support. That might be enough for that module to pull its own weight. If released to CPAN (under an appropriate name), it would also give users more choices of modules to pick from, which I think is good in principle.

As for my module being in “excellent shape”, that may well be another exaggeration. 😄 But it does work, and my intention is to keep it working, at least as far as potential future changes to PROJ will permit.

Geo::LibProj::FFI isn’t a 100 % implementation either though. Some of the more advanced PROJ features are difficult to use through FFI::Platypus. That may be another reason why an XS or Inline module like the one discussed above could perhaps be a useful addition to CPAN. Although its focus at present seems to be simplicity rather than completeness, so this aspect might perhaps not be relevant.

---

As for Geo::Proj4 itself, I think adding pointers to all potential alternatives that are available on CPAN would make sense.

Beyond that, it should be possible to get Geo::Proj4 working again by having it use Alien::proj4. I think Slaven sent a patch for that in RT 129389. Then Geo::Point etc. would also work again. Yes, PROJ 4.x is badly outdated, but for simple mapping work (not geodetic), it’s probably still acceptable.

I might be interested to look into that, but don’t have a lot of free time at this particular moment. May I ping you for co-maintainer privs on PAUSE when that changes?

[markov2]

As I investigated, Alien::proj4 will make Geo::Proj4 link to proj4 libraries as well. But that's not the problem which needs to be solved, which are library incompatibilities with proj4.

I have so many other projects on my hands, that I will not get involved in any proj business soon.

[johannessen]

Well, just an offer. 🙂 Do get in touch if you feel that I can help.

[pdean]

I have added a new example to my module. It simply converts a file of grid coordinates to geodetic, then simply creates a simple kml with XML::Simple. See https://github.com/pdean/geo-proj-cct/tree/main/examples/kmlout

It occurs to me that if I used a namespace with "Simple" in its name, that that may be acceptable. Any suggestions?

[johannessen]

More descriptive names are generally better choices.

From the page On The Naming of Modules on PAUSE:

Avoid Simple, Easy, Reduced, Tiny, Fast, Small, Super, Hyper

The terms Simple, Easy, Reduced, and Tiny are some of the worst parts of the names on CPAN. They all indicate that the module is a variation of another module, but why is that variation interesting? It's usually missing or hiding some features, less flexible than the original, and in most cases, tailored to the task the author needed. What is that task though? Making it easy for you doesn't mean it's easy for the next programmer.

[pdean]

Fair enough, although I did wc -l on cpanp simple and got 2339 If it's ok, I'll run with Mark's suggestion of Geo::ProjX::CCT. I need to tidy up the docs first. I am now officially pdean on cpan though I haven't uploaded anything. I am very new to perl5 although I wrote some perl4 back in about 1993!