[ANN] Proj4.jl

[Chris Foster]

Hi all,

I've just written a basic wrapper around proj.4, available here:

https://github.com/FugroRoames/Proj4.jl

Since the proj API is so small, I've wrapped this by hand (which was
also a useful exercise in learning some basic ccall() usage.) Simple
usage should work, allowing you to transform between the huge range of
cartographic projections supported by libproj.

At this stage I don't know a lot about the subtle details of using
proj.4, so any advice on things I've got wrong or obvious omissions
would be appreciated. I haven't added support for transformation
contexts yet since I don't quite know where I'll need them. pyproj
seems to allocate a new one of these for each transformation object
which seems a bit excessive, but maybe there's a good reason for that.

Another rather basic thing I'm not sure about is whether to call this
Proj4.jl, or simply Proj.jl. The C library generally seems to be
referred to as proj.4 (including the project name on github), but some
other wrappers seem to omit the .4 suffix.

Cheers,
~Chris

[Mauro]

Nice, thanks! I should have use for this in a few months. Maybe call
it Proj.4.jl?

[Yeesian Ng]

This is great, thanks! Might you be interested in migrating it to the JuliaGeo organization (and being part of it)?

Just to throw up another name for consideration: LibPROJ.jl (alongside LibGEOS.jl, and [at some point] LibOGR.jl)?

Having the Lib- prefix usually suggests that it's a wrapper around a C library (at least for JuliaGeo), as compared to a direct port written in Julia.

[Chris Foster]

On Fri, Aug 28, 2015 at 4:17 AM, Yeesian Ng <ngye...@gmail.com> wrote:
> This is great, thanks! Might you be interested in migrating it to the
> JuliaGeo organization (and being part of it)?

Thanks! Personally I'd happily move this to JuilaGeo, but before I do that
I'd have to get internal agreement at Fugro Roames (who are kindly letting
me code parts of this at work) regarding attribution - everyone likes to have
some credit for making projects happen, and I hope this is just the first of
many ;-)

> Just to throw up another name for consideration: LibPROJ.jl (alongside
> LibGEOS.jl, and [at some point] LibOGR.jl)?
>
> Having the Lib- prefix usually suggests that it's a wrapper around a C
> library (at least for JuliaGeo), as compared to a direct port written in
> Julia.

Right, that might make sense. I'd prefer to follow whatever
convention there is in the wider julia community. An additional
confusing thing is that it's not really clear what the proper name is
for the C library. As installed, it's just "libproj" on linux, and
reports itself as version 4.8.0. Concievably I suppose there might be
a version 5 in the future which would suggest dropping the version
number.

BTW, I'm holding off registering in METADATA.jl at least until the
naming is sorted out, and probably until I have a proper build.jl to
install the library dependency, at least on linux where it's
relatively easy for me to test.

> On Thursday, 27 August 2015 10:32:55 UTC-4, Mauro wrote:
>>
>> Nice, thanks! I should have use for this in a few months. Maybe call
>> it Proj.4.jl?

I'm afriad that won't work - the module name should be the same as the
repo name, and Proj.4 is not a valid julia identifier.

Cheers,
~Chris

[Mauro]

>>> Maybe call it Proj.4.jl?
>
> I'm afriad that won't work - the module name should be the same as the
> repo name, and Proj.4 is not a valid julia identifier.

You're right, silly me. M

[Chris Foster]

No problem, thanks for the suggestion.

Having a look through METADATA.jl, it seems to me that LibBlah isn't a
really common convention in the wider julia community so it might make
sense just to call it Proj.jl. On the other hand, "Proj" is a really
generic name.

> --
> You received this message because you are subscribed to the Google Groups "julia-geo" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to julia-geo+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Yeesian Ng]

Indeed it isn't always adopted. The JuliaOpt packages, for instance, do not follow such a convention. On the other hand, there is a precedent in METADATA where a package had the Lib- prefix added to its name, e.g. Curl -> LibCURL.

Personally, I think "Proj" is too generic a name, but "Proj4" is fine (as mindshare within the wider geo community). If you prefer to ditch the "4", I think the better candidates are still "PROJ" or "LibPROJ".

[Chris Foster]

After looking at a bunch of wrappers/ports, it looks like a '4' is
usually included in the name, so I'm just going to keep Proj4.jl after
all (https://github.com/FugroRoames/Proj4.jl/issues/2). Sorry for the
noise!

[J Luis]

Chris, for the other issue with the visualization with displaz on Windows I made this change in Proj4.jl

#const libproj = "libproj"
WORD_SIZE == 64 ? suffixed_name = "proj_w64" : suffixed_name = "proj_w32"
const libproj = Libdl.find_library(["libproj", "proj", suffixed_name])
if isempty(libproj)
    error("could not find Proj4 library")
end

the 'proj_w64.dll' comes with the GMT Windows installer, whilst the proj.dll can be found in the gisinternals zip file

Joaquim

[Chris Foster]

On Sat, Dec 19, 2015 at 4:50 AM, J Luis <jmf...@gmail.com> wrote:
> Chris, for the other issue with the visualization with displaz on Windows I
> made this change in Proj4.jl
>
> #const libproj = "libproj"
> WORD_SIZE == 64 ? suffixed_name = "proj_w64" : suffixed_name = "proj_w32"
> const libproj = Libdl.find_library(["libproj", "proj", suffixed_name])
> if isempty(libproj)
> error("could not find Proj4 library")
> end
>
> the 'proj_w64.dll' comes with the GMT Windows installer, whilst the proj.dll
> can be found in the gisinternals zip file

Right, thanks. One of the reasons I still haven't released an
official version of Proj4.jl is that I've been too busy to make a
systematic way of building the windows binary, given that there
doesn't seem to be any official binary release. If I could rely on
binary releases from a trusted third party that would also be ok -
osgeo4w comes to mind, but they have their own installer system which
is a bit opaque to me as an outsider. Do you have any suggestions
about the best strategy for getting a reliable windows binary of proj4
by itself? I'd like to avoid the user having to download a large
package such as gisinternals.

Thanks,
~Chris

[Chris Foster]

On Sat, Dec 19, 2015 at 11:54 AM, Chris Foster <chri...@gmail.com> wrote:
> Right, thanks. One of the reasons I still haven't released an
> official version of Proj4.jl is that I've been too busy to make a
> systematic way of building the windows binary

I made an issue to deal with this. Hopefully I'll get some time soon.

https://github.com/FugroRoames/Proj4.jl/issues/8

[J Luis]

Well, what about hosting the dlls in github/proj4? They are relatively small (300 KB) and could be removed after the Pkg.install()  if found to live already in the installing target.
Otherwise, I have the same type of doubts on how to deal with GMT for example. I certainly will not want to force install it under .../.julia via Pkg

[Chris Foster]

I'm not sure what else I'd do on windows, other than install it under
.julia/Proj4/deps or something - it's not like there's a standard
windows package manager.

I definitely wouldn't host proj.dll in the git repository because
it'll bloat up the git history for everyone, not just windows users.
If I was to manage it myself (rather than relying on a dll from a
third party), I'd probably put some build scripts in a new repo
proj4_deps, automate the build via appveyor and publish the artifacts
as released binaries on the proj4_deps repo. That would avoid ever
storing dlls in git itself, which I'm really not keen on.

At the moment I'm leaning toward just using the osgeo4w package
manager, and installing the dll inside .julia/Proj4/deps. I think
there's quite a lot of precedent for packages installing their binary
dependencies that way.