Howard Butler | 4 Mar 18:36 2015
Picon

proj 4.9.1RC5 released

All,

I have issued a RC5 which moved the problematic test into its own, manual, test script, and Charles has made
some CMake tweaks. Unless significant issues are identified, I will motion this for release by the
MetaCRS committee on Friday.

http://download.osgeo.org/proj/proj-4.9.1RC5.tar.gz

Howard

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

Luís de Sousa | 26 Feb 10:53 2015
Picon

How to use proj from a Ruby application

Dear all,

I am trying to use Proj from a Ruby application. There are various
Ruby libraries out there [0, 1] typically called "proj4rb"; none seems
to have had active development for multiple years and so far I was not
able to install any of them [2].

What other alternatives are there to use proj with Ruby?

Thank you,

Luís

[0] https://github.com/cfis/proj4rb

[1] https://github.com/Caged/proj4rb

[2] http://gis.stackexchange.com/questions/136550/how-to-install-proj4rb-on-ubuntu-14-04
_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj
Bernhard Jenny | 24 Feb 05:03 2015
Picon

Patterson and Compact Miller projections

All,

Attached is code for the Patterson and the Compact Miller projections for addition to PROJ.4.

The Patterson projection is a cylindrical described here: http://shadedrelief.com/patterson/
Also see Ticket #252: http://trac.osgeo.org/proj/ticket/252 

The Compact Miller is another cylindrical described in this paper: http://cartography.oregonstate.edu/pdf/2015_Jenny_etal_ACompromiseAspect-adaptiveCylindricalProjectionForWorldMaps.pdf

Below are a few test points for both projections.

Thank you,
Bernie Jenny

Assistant Professor
Cartography and Geovisualization
Oregon State University
jennyb <at> geo.oregonstate.edu
http://cartography.oregonstate.edu/

Patterson projection (lon, lat, 0, X, Y):

0 0.0 0 0.0 0.0
0 22.5 0 0.0 2551415.729669344
0 45.0 0 0.0 5366413.421153781
0 67.5 0 0.0 8729502.054111844
0 90.0 0 0.0 1.1409566822831295E7
45 0.0 0 5003778.588046594 0.0
45 22.5 0 5003778.588046594 2551415.729669344
45 45.0 0 5003778.588046594 5366413.421153781
(Continue reading)

ed | 23 Feb 18:51 2015
Picon

Proj 4.9.1RC3 Released

Hi Howard and all,
I have a small suggested addition to the 4.9.1 Release Notes. It would be nice to add a bullet:
o Added the CalCOFI pseudo-projection, #135I'm very happy that this will be re leased soon. Thanks for your help,EdEdward D. Weber, Ph.D. Research Fisheries Biologist NOAA Southwest Fisheries Science Center 8601 La Jolla Shores Drive La Jolla, CA 92037, U.S.A. (858) 546-5676 ed.weber <at> noaa.gov
_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj
Howard Butler | 21 Feb 18:31 2015
Picon

Proj 4.9.1RC3 Released

All,

Proj4 4.9.1RC3 is now released for testing. Should no significant issues be identified, this is the last
release candidate, and I will motion the MetaCRS list to promote it to final on Wednesday.  

Thanks for testing the past two RC's.

Howard

http://download.osgeo.org/proj/proj-4.9.1RC3.tar.gz

> 4.9.1 Release Notes
> -------------------
>  
>  o 4.9.0RC2 release was abandoned because it was not promoted in a 
>    timely fashion. Subsequent maintenance of tickets has continued, 
>    and a new 4.9.1 release was issued in its place.
> 
>  o Implement inverse solution for Winkel Tripel from Drazan Tutic #250
> 
>  o More CMake configuration tweaks. The CMake configuration is probably 
>    not at feature parity with the autotools builds at this point but it 
>    is converging #256
>  
>  o Tweak initialization ordering around setlocal which may have caused
>    issues #237
> 
>  o Support out-of-tree autoconf builds more completely #247
> 
>  o Fix NaN handling by geod_inverse and geod_polygon_addedge #251 & #253
> 
>  o Update config.sub and config.guess #257
>  
>  o Adapt Charles Karney's CMake patches for smoother build #258
> 
>  o Define default PROJ_LIB location for CMake compilation #261
> 
>  o Fix Windows compilation on PJ_aitoff.c
> 
>  o Align CMake SOVERSION with autotools #263
> 
>  o Regenerate nad/epsg with GDAL r28536 to avoid precision loss in TOWGS84
>    parameters, e.g. on Amersfoort / RD EPSG:4289 (#260)

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

Adri CS | 18 Feb 10:22 2015
Picon

Re: Differences in reprojection between using the cs2cs app and using the api

Hello!!

Hermann code is fine. After a new review, I've found the cause of the disparities between cs2cs and my code's output: I forgot to set the number of decimals places in the output file.

Thank you all for your help! :)

On 16 February 2015 at 18:41, Adri CS <acsantome <at> gmail.com> wrote:
Hi!

Thanks for your time! Your code works fine! I'll check mine tomorrow morning and see where I messed up.

Thanks a lot!

On 15 February 2015 at 09:41, Hermann Peifer <peifer <at> gmx.eu> wrote:
Adri,

Just to confirm that using the API doesn't make any difference, as expected. See mycode.c below, based on https://trac.osgeo.org/proj/wiki/ProjAPI

Your own sample code below has these coordinates:
> /double lat = -45.491596;
> /double lon = -23.570147;

This point falls into the South Atlantic Ocean, somewhere in the middle between Tierra del Fuego and Cape Town. So you'd have to swap lat/lon in order to get to the Rodovia dos Tamoios, (SP-099).

Hope this helps, Hermann

$ echo -45.491596 -23.570147 769.750000 | ./mycode
449834.145105   7393276.784821  769.75

$ cat mycode.c
#include <stdio.h>
#include <proj_api.h>

int main(int argc, char **argv) {

        projPJ wgs, sirgas;
        double lon, lat, alt;

        if (!(wgs = pj_init_plus("+init=epsg:4326")) )
                exit(1);

        if (!(sirgas = pj_init_plus("+init=epsg:31983")) )
                exit(1);

        while (scanf("%lf %lf %lf", &lon, &lat, &alt) == 3) {
                lon *= DEG_TO_RAD;
                lat *= DEG_TO_RAD;
                pj_transform(wgs, sirgas, 1, 1, &lon, &lat, &alt);
                printf("%.6f\t%.6f\t%.2f\n", lon, lat, alt);
        }
        exit(0);
}


On 2015-02-11 18:07, Adri CS wrote:
Hi,

I built Proj4 4.8.0 for Windows with MinGW. I'm trying to reproject some
WGS84 lat/long coordinates (degrees) from Brazil to UTM Sirgas 2000. The
UTM zone would be 23S.

**) Using the cs2cs app:

/cs2cs.exe -f %.6f +init=epsg:3273 +proj=latlong +to +init=epsg:31938
input.txt > output.txt/

**The input file would contain coords like this: -45.491596
-23.570147 769.750000

And the output would be: 449834.145105    7393276.784821 769.750000

/***********************************************/

**) Using the api (I omit the error checking):

/projPJ wgs = pj_init_plus("+init=epsg:32723 +proj=latlong");
/
/projPJ sirgas = = pj_init_plus("+init=epsg:31983");
/
/double lat = -45.491596;
/
/double lon = -23.570147;
double alt = 769.750000;

/
/lat *= DEG_TO_RAD;
/
/lon *= DEG_TO_RAD;
/
/
/
/pj_transform(wgs, sirgas, 1, 1, &lon, &lat, &alt);/

This outputs: 449834.127632      7393276.821296       769.750000

In both cases, the left part of the returned UTM easting and northing
coordinates are the same, but the numbers after the decimal point are
different.

I'm only transforming the input lat/lon coordintates when using the api,
since if I transform them before calling cs2cs, it will output wron
coords (the easting will have 7 digits before the decimal points).

What's happening here? The only difference I can see it's the
transformation of the lat/lon coordinates from degrees to radians: I'm
multypling directly while in the cs2cs source, there's a call to the
/dmstor/ function (which I can't call directly, it seems).

Thanks for your time & cheers!
Adri.


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




_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj
Kyle Shannon | 12 Feb 17:06 2015
Picon

Fwd: PROJ.4 Maintainer


-------- Forwarded Message --------
Subject: PROJ.4 Maintainer
Date: Thu, 12 Feb 2015 08:43:25 -0700
From: Kyle Shannon <kyle <at> pobox.com>
To: metacrs <at> lists.osgeo.org

It seems proj has fallen through the cracks.  RC1 for 4.9.0 had a motion
to promote in October, and has little attention since.  I feel like proj
is kind of important for many packages.  Can someone review and promote?
  I would be willing to help if needed, if I can.

kss

--

-- 
Kyle

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

Adri CS | 11 Feb 18:07 2015
Picon

Differences in reprojection between using the cs2cs app and using the api

Hi,

I built Proj4 4.8.0 for Windows with MinGW. I'm trying to reproject some WGS84 lat/long coordinates (degrees) from Brazil to UTM Sirgas 2000. The UTM zone would be 23S.

**) Using the cs2cs app:

cs2cs.exe -f %.6f +init=epsg:3273 +proj=latlong +to +init=epsg:31938 input.txt > output.txt

**The input file would contain coords like this: -45.491596     -23.570147 769.750000

And the output would be: 449834.145105    7393276.784821 769.750000

/***********************************************/

**) Using the api (I omit the error checking):

projPJ wgs = pj_init_plus("+init=epsg:32723 +proj=latlong");
projPJ sirgas = = pj_init_plus("+init=epsg:31983");
double lat = -45.491596;
double lon = -23.570147;
double alt = 769.750000;

lat *= DEG_TO_RAD;
lon *= DEG_TO_RAD;

pj_transform(wgs, sirgas, 1, 1, &lon, &lat, &alt);

This outputs: 449834.127632      7393276.821296       769.750000

In both cases, the left part of the returned UTM easting and northing coordinates are the same, but the numbers after the decimal point are different.

I'm only transforming the input lat/lon coordintates when using the api, since if I transform them before calling cs2cs, it will output wron coords (the easting will have 7 digits before the decimal points).

What's happening here? The only difference I can see it's the transformation of the lat/lon coordinates from degrees to radians: I'm multypling directly while in the cs2cs source, there's a call to the dmstor function (which I can't call directly, it seems).

Thanks for your time & cheers!
Adri.
_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj
Mikael Rittri | 8 Feb 11:26 2015

Is it possible to store a WGS84 / Pseudo Mercator image as a GeoTIFF?

And if it is possible, since when or what version of
GeoTIFF? And do most GeoTIFF readers support it?

(I apologize if this is the wrong mailing list for the questions.)

I am writing a report on Pseudo Mercator, and I realized
that I don't know how well it is supported in GeoTIFF.

Best regards,

Mikael Rittri
Carmenta
Sweden
http://www.carmenta.com
_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj

Chris Crook | 5 Jan 09:01 2015
Picon
Picon

Time dependent coordinate transformations

I'm wanting open a discussion around how to handle time dependent coordinate transformations.  These are
becoming far more relevant to GIS data sets and positioning than they have historically been.

This is a growing issue for which I'd like to find the right forums and process to ultimately have have widely
supported in coordinate transformation implementations, so please suggest or forward other
appropriate forums.

I'm posting initially to the PROJ list as PROJ underlies much of the coordinate system transformations in
the open source GIS stack, and does include datum transformations as well as projections.  However this is
clearly a wider issue .. as I suggest below I think this affects the definition of spatial features
generally - so I'd welcome suggestions for more appropriate or additional forums.

The background
==============

Coordinate systems are based on geodetic datums.  These are generally either international datums, such
as WGS84 or ITRF realisation, or national datums defined by a country's geodetic authority.

Within international datums apparently fixed features (such as buildings) are moving due to plate
tectonics at rates of typically 5 cm/year.  This means that the WGS84 coordinate of a "fixed" point in 2000
would now miss that point by 75cm.

National datums are generally referenced to fixed marks within the country and provide a stable
coordinate system, such that the coordinates of fixed marks are constant.

Obviously the conversion between international datums and national datums cannot be done without taking
account of when the coordinates are applicable.

Typically GIS systems are in terms of national coordinate systems.  Generally they contain spatial
definitions in terms of the national datum, with no timestamp, and assume that this provides a consistent
coordinate system for comparing coordinates and performing the various spatial analyses that
characterise GIS systems.  Features are generally assumed to be fixed, and operations such as testing
overlaps and adjacency assume that the spatial defintions are in a common spatial reference frame.

Historically most data has been derived by observations relative to the national coordinate system and
this has worked.

Now however precise point positioning systems are increasingly generating data in terms of
international reference frames.  Similarly global systems such as satellite based remote sensing will
generate data in terms of international reference frames.

How are these data to be brought to a common system and used within GIS systems?

Clearly this cannot be accomplished to sub-metre accuracy without time dependent transformations that
account for tectonic movement.

What do the time dependent transformations look like?

On stable continents they are simply an extension of the Bursa-Wolf 7 parameter transformation in which
each parameter also has an additional term representing its rate of change. Also there is a further
parameter which is the reference date at which the time dependent component is zero.

However many countries also include deforming areas near tectonic plate boundaries which require more
special treatment.  For example North America has the HTDP model which describes the deformation of the
western edge of the continent on the North American/Pacific plate boundary lies.  In New Zealand the
entire country straddles a plate boundary, and so the national datum is related to ITRF96 by a complex
deformation model including a gridded velocity model, and gridded components for significant earthquakes.

The issues for the GIS software stack
=====================================

I believe there are two issues facing GIS systems in handling time based transformations.

1) Where are the parameters of time based transformations defined

2) When transforming a coordinate how is the time parameter included in the transformation API

It seems fairly straightforward to expand the definitions of coordinate systems in PROJ and the EPSG
registry to include additional parameters.  The to_wgs84 parameters could readily be extended to
include the 14 parameter plus reference epoch time dependent Bursa Wolf transformation.  Some datum
transformations already include nested grids, so extending this to include grids with associated time
functions also seems feasible.

However to be widely supported this will need appropriate standards to be defined for the common parameter
sets of time dependent transformations.  (There may also a question of what reference datum the
transformations are defined in terms of, if any.  The to_wgs84 parameters implies a WGS84 based reference
datum, but in fact WGS84 is a series of datum realisations)

The second question is how a time parameter is supplied to a transformation function.  Logically this is
associated with a feature.  Where the feature is not fixed in terms of the coordinate system it is not really
meaningful to define coordinates without specifying an epoch at which they apply.  For example the
ITRF2008 coordinates of a survey mark on a tectonic plate are correct only at the time at which they are
measured.  So properly the time is part of the coordinate definition of a feature.

Where a feature is considered to be fixed in terms of a coordinate system the time can be discarded - this is
the case for nearly all features in GIS systems today.  Because the feature is considered fixed, any time
can be associated with the spatial definition for the purposes of transforming to another coordinate system.

I suspect that providing for a time coordinate as part of the spatial definition of features would involve
modifying the OGC standard defining spatial features, as well as the various software stacks using them.

Summary
=======

So to paraphrase:

* coordinate transformations between international and local datums at sub-metre accuracy requires
time dependent transformations
* coordinate system definitions therefore need to be expanded to allow defining time dependent
parameterization in standard ways that can be widely implemented
* spatial definitions of features need to be expanded to include a time component, again so that this can be
accessed in a standard way

Does this conclusion seem correct, and if so what is the process of making this happen?

This message contains information, which may be in confidence and may be subject to legal privilege. If you
are not the intended recipient, you must not peruse, use, disseminate, distribute or copy this message.
If you have received this message in error, please notify us immediately (Phone 0800 665 463 or
info <at> linz.govt.nz) and destroy the original message. LINZ accepts no responsibility for changes to
this email, or for any attachments, after its transmission from LINZ. Thank You.
_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj

Charles Karney | 20 Dec 15:33 2014

Rhumb lines and Mercator on a triaxial ellipsoid

It is well known that a rhumb line arrives at a pole in a finite
distance after encircling the pole infinitely many times.  Craig Rollins
recently asked me what heading a rhumb line has *after* passing through
the pole.

One way of answering this is to consider a rhumb line on a triaxial
ellipsoid and to take the limit as the two large axes approach one
another.  The (somewhat surprising) result is that the heading of the
rhumb line is reversed.  E.g., if the initial heading is NE, the heading
after passing through the pole is SW.

This got me to thinking about the Mercator projection on a triaxial
ellipsoid.  This was given by Jacobi in 1843, see section 28 of

   https://www.worldcat.org/oclc/440645889

The integrals that Jacobi gives can be written in terms of elliptic
integrals, see

   https://dx.doi.org/10.1007/978-3-642-32618-9_17
   http://geographiclib.sf.net/html/triaxial.html#triaxial-conformal

Finally, Jacobi has an interesting take on Gauss' work on conformal
projections (excerpted from Balagangadharan's translation):

   "Among the different ways of representing a curved surface on a plane,
   as is necessary for a map, one prefers, above all, the method of
   projection in which infinitely small elements remain similar.  In the
   preceding century Lambert had been concerned with various aspects of
   this projection, of which one can learn in detail from his
   contributions to mathematics.  Because of these, Lambert's colleague
   at that time, Lagrange, was induced to undertake an investigation from
   the same standpoint and gave the solution completely for all surfaces
   of revolution.  The Copenhagen Academy which later announced a prize
   for the solution of this problem for all curved surfaces awarded it to
   the treatise sent in by Gauss.  In this, Lagrange's work, to which
   only little had to be added, finds no mention."
_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj


Gmane