Even Rouault | 25 Aug 17:46 2015

Confused by git branch management

Hi,

I've just pushed a fix to trunk and branch/4.9, the latest I assumed to be the 
one that would gave a proj 4.9.2, but when digging more, it appears this 
branch/4.9 is really outdated (https://github.com/OSGeo/proj.4/commits/4.9).
It looks like it is basically 4.9.0 plus a couple of fixes I committed 
afterwards.

I'm wondering if it wouldn't be appropriate to :
1) kill this branch/4.9
2) copy tag/4.9.1 as branch/4.9 (or from the master commit that corresponds)
3) and reapply on top of the relevant commits

I guess this would translate to 
1) git push origin :4.9
2) git checkout tag/4.9.1
    git branch -b 4.9
    git push origin 4.9
3) git cherry-pick ...

But my git abilities are limited, so advice would be welcome, in case we agree 
this is the right strategy.

Even

--

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
Proj mailing list
(Continue reading)

Charles Karney | 13 Aug 22:46 2015

degree to radian conversions

I just submitted a pull request for proj.4 to correct the values of the
constants used in degree/radian conversions.  The important change was
to use

   .0174532925199432958

instead of

   .0174532925199433

as the value of pi/180 used to convert degrees to radians in dmstor.c.
The new value is substantial closer to the true value...

   cos(90 * .0174532925199432958) =  6.1e-17
   cos(90 * .0174532925199433)    = -3.8e-16

Needless to say, some of the tests now fail.  Particularly because
proj.4 used to round 90 deg to an illegal latitude (larger than pi/2).

However the changes for the healpix checks are inexplicably large.

It would be good if someone could figure out why the healpix results
change so much.

   --Charles
_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj

(Continue reading)

Frank Willett | 3 Aug 20:50 2015
Sorry for the earlier post. Fat fingers strike again. PBKAC

Frank Willett
_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj

Frank Willett | 3 Aug 18:47 2015

Fwd: [#KXI-953237]: Barracuda Problem

From WebHostingPad ... hope this works now!


-------- Forwarded Message -------- Subject: Date: From: Reply-To: To:
[#KXI-953237]: Barracuda Problem
Mon, 03 Aug 2015 11:27:00 -0500
WebHostingPad Support <support <at> webhostingpad.com>
support <at> webhostingpad.com
fyw <at> wwwtools.com


Hello Frank, Thank you for your patience on this. You should be able to see the login information email with subject "User Quarantine Account Information" in the inbox of email account jorge <at> wwwtools.com. Please check. Please let us know if there's anything else we can assist you with. Regards, Victor K, Senior System Administrator. http://webhostingpad.com KB: http://webhostingpad.com/knowledgebase Video Tutorials: http://www.webhostingpad.com/demos/ Submit your Feedback at http://webhostingpad.com/feedback Ticket Details =================== Ticket ID: KXI-953237 Department: Admin Priority: default Status: On Hold

_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj
Rob Parsons | 10 Jul 05:48 2015
Picon

Verifying cs2cs arguments

Hello,

Is there a way to verify the arguments that will be passed to cs2cs.exe before cs2cs.exe is used?

cs2cs.exe is used from inside a python script. Is there a related tool that can verify the arguments that will be passed to cs2cs.exe?

Rob Parsons
Raleigh NC

_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj
Even Rouault | 7 Jul 18:53 2015

Next major proj version: 4.10 ?

Hi,

What will be the number of the next major proj version : 4.10 ?

I'm wondering so as to be able to close a ticket and set the appropriate 
milestone (4.10 doesn't exist currently in github tickets)

Currently, we have:

#define PJ_VERSION 491

I guess that with 4.10 that should become :

/* MAJOR * 10000 + MINOR * 100 + MICRO */
#define PJ_VERSION 41000

Even

--

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj

OHTSUKA Ko-hei | 6 Jul 02:28 2015
Picon

Can I make definitions of bird-eye-view maps coordinates using proj4 and proj4text?

Hello,

I used proj.4 for transforms of many maps projections, but those projections are ordinary maps'
projection, like stereographic, orthographic, gnomonic .. and so on.

But these days, I have a question if proj.4 can use for bird-eye-view maps projection.
Are there any options for making definition of bird-eye-view maps in proj4text?

Regards, 
Ko-hei
_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj
Even Rouault | 4 Jul 21:13 2015

AppVeyor (Windows CI) setup + Windows CMake question

Hi,

Similarly to Linux Travis-CI builds, I've also added the configuration for the 
AppVeyor hosted CI service for Windows builds 
:https://github.com/OSGeo/proj.4/blob/master/appveyor.yml

The following configurations are tested (for pushes and pull requests) :
Environment: BUILD_TYPE=cmake, VS_VERSION=Visual Studio 10; Platform: x64
Environment: BUILD_TYPE=cmake, VS_VERSION=Visual Studio 10; Platform: x86
Environment: BUILD_TYPE=cmake, VS_VERSION=Visual Studio 11; Platform: x64
Environment: BUILD_TYPE=cmake, VS_VERSION=Visual Studio 11; Platform: x86
Environment: BUILD_TYPE=cmake, VS_VERSION=Visual Studio 12; Platform: x64
Environment: BUILD_TYPE=cmake, VS_VERSION=Visual Studio 12; Platform: x86
Environment: BUILD_TYPE=nmake; Platform: x64
Environment: BUILD_TYPE=nmake; Platform: x86

This only runs the build as I don't think there's a test target for Windows ?

Results available at:
https://ci.appveyor.com/project/OSGeo/proj-4

Travis and Appveyor badges displayed on:
https://github.com/OSGeo/proj.4/wiki

I've had a hard time with Windows cmake builds. I had to add  "-
DCMAKE_RUNTIME_OUTPUT_DIRECTORY_RELEASE=../bin" on the cmake line, otherwise I 
got errors during the build with "..\bin\nad2bin.exe" not being found when 
processing """
CustomBuild:
  Building Custom Rule c:/....../proj.4/nad/CMakeLists.txt
"""
Is it expected?
Without that, the binaries are installed in bin\Release

Even

--

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj

Darren Govoni | 3 Jul 13:35 2015

Custom grid system?

Hi,
   I'd like to create custom grid reference systems with proj4 
(specifically pyproj).
So I want to a method to create all the individual grids and have them 
in a matrix or something.

Are there examples of this? I couldn't find any.

Thanks
_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj

José Luis García Pallero | 2 Jul 16:25 2015
Picon

PROJ.4 and OpenMP

Hello:

Since version 4.8.0, PROJ.4 has some thread safety facilities
(https://trac.osgeo.org/proj/wiki/ThreadSafety) and also the source
code contains an example program in which Posix Threads are used. But
I'm a bit confused about how to use this thread safety with OpenMP.
Could someone, please, upload a code example of using PROJ with
OpenMP? Such example could be also added to the distributed source
code

Thanks

--

-- 
*****************************************
José Luis García Pallero
jgpallero <at> gmail.com
(o<
/ / \
V_/_
Use Debian GNU/Linux and enjoy!
*****************************************
_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj
Even Rouault | 23 Jun 17:29 2015

Experiment to speed up proj.4 by 2 or more

Hi,

I've done an experiment to use Intel SIMD intrinsics 
(https://en.wikipedia.org/wiki/SIMD), and I think they could be beneficial for 
proj, when called to transform several coordinates at a time.

I've used the SSE2 instruction set (128 bit registers, so 2 doubles at a 
time), and I managed to speed up the inverse Transverse Mercator ellipsoidal 
transformation (ie. from projected to geodetic) by a factor of ~ 2 (excluding 
potential datum transformations)

One key for performance was to find an efficient way of computing the usual 
transcendental functions (ie. sin, cos, tan and their inverse, exp, ln, 
etc...) with SIMD registers, since they are not included in the instruction 
set. Otherwise you have to collect each component of the SIMD register, 
evaluate it with the x87 coprocessor, and reassemble the SIMD register from 
the computed components, which kills all the other performance gains. The 
SLEEF library (http://freecode.com/projects/sleef) has such routines, is in 
the public domain and works rather well (with gcc/clang, although it has some 
rough edges when trying with MSVC, but nothing that cannot be overcome)

I've encapsulated the use of SSE2 intrinsics in a C++ class with overloading 
of arithmetics operators, so the resulting code looks pretty much similar to 
the original C code, which is great for readability (although the original C 
code isn't always very readable ;-)), and confidence that it doesn't introduce 
errors. Conditionnal branches are not so great for SIMD performance, but there 
are tricks to rewrite some of them with a ternary-like operator.

SLEEF also supports the AVX & AVX2+FMA instruction sets (256 bit registers), 
which could also lead to a further ~ x2 gain over SSE2.

So I was wondering if there was :

1) interest of the project in pursuing into that approach (which involves  
introducing C++ in the code base, as an implementation detail, the interface 
being unchanged). We could imagine to have the same source files compiled 
several times with different register sizes, with runtime selection of the 
appropriate variant (note: SSE2 is guaranteed to be available on all x86_64 
compatible processors. AVX/AVX2 is for more recent CPUs).

2) ... and sponsors interested in making that happen.

Finally, the proof of concept: 
* regular code (runs in ~30s on Core i5 750  <at>  2.67GHz  ): 
   https://gist.github.com/rouault/946104d0b98e8e8cc564
* SSE2 code (~14s):
   https://gist.github.com/rouault/3bbc31c9f12391d79920

Best regards,

Even

--

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj


Gmane