Matteo Pasquini | 9 Jun 14:51 2016

help

Hi,

 

I’ve added a new projection to the code, tested and installed on my laptop. It works.

 

I would like to push it for you approval but, following the instructions from https://github.com/OSGeo/proj.4/blob/master/HOWTO-RELEASE ,

I’m unable to perform latest passages.

I’m stuck after the “make dist-all”

 

Which is the way to send those changes to you ?

 

 

Matteo Pasquini
OPS - Production Agent

Skype : Pasquini.Matteo

Mobile: 331-595-8761

 

                 

 

_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj
Thomas Knudsen | 5 Jun 05:46 2016
Picon

Transformation pipelines - your opinion?

All,

I have recently opened a new pull request over at
https://github.com/OSGeo/proj.4/pull/388 ...

It introduces projection pipelines (i.e. multi-step transformations),
and, at the end-user facing side of things, a new 3D transformation
program called “tran”, which directly supports transformation
pipelines.

While the pull request expands the capabilities of proj.4
dramatically, the code is not very intrusive: Technically, the
pipeline driver is just a new projection, and hence a transformation
pipeline is introduced with the incantation “+proj=pipeline”.

I agree that at first, this may seem a bit odd, so I hope to initiate
a discussion here about e.g. the syntax, and aboult potentially useful
pipeline primitives: The code is still in its infancy, so a lot will
happen before it is ready for merging into the proj.4 master branch
(although I hope it can be done in time for version 4.10)

You can contribute to the discussion here and/or over at the github
page already mentioned. Also, you can read more about syntactic
details at my proj.4 page http://thomasknudsen.net/proj4.html, where
you can also find instructions for downloading a recent Windows build
of the “tran” tool.

/thomas
_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj
dzengiz.tafa | 1 Jun 10:51 2016
Picon
Gravatar

placing a matplotlib basemap plot on a google map

Hi

For quite some time now I've been wresteling with a problem concerning projections. I was wondering if the experts on this forum/mailinglist could be of any help, since (let's face it) the material is quite frankly over my head.

The short story is that I have got an hdf5 radar image, which contains an x-y grid of pixelvalues and I have to place it on a google map. Already there's a problem because the data is purely an x-y grid and google maps uses the EPSG 3857projection. The proj4 string provided in the hdf5 file is one of the RD-coordinate system, a system used in the Netherlands.

The rest of the information I can find is listed here

cal_data_count = 0
cal_method = None
cal_stations_count = 0
composite_count = 288
declutter_history = 0.1
declutter_size = 4.0
fill_value = -9999
grid_extent = -110000,390000,700000,210000
grid_projection = PROJCS["unnamed",GEOGCS["Bessel 1841",DATUM["unknown",SPHEROID["bessel",6377397.155,299.1528128],TOWGS84[565.237,50.0087,465.658,-0.406857,0.350733,-1.87035,4.0812]],PRIMEM["Greenwich",0],UNIT["degree",0.0174532925199433]],PROJECTION["Oblique_Stereographic"],PARAMETER["latitude_of_origin",52.15616055555555],PARAMETER["central_meridian",5.38763888888889],PARAMETER["scale_factor",0.999908],PARAMETER["false_easting",155000],PARAMETER["false_northing",463000],UNIT["Meter",1]]
grid_size = 500,490
locations = -7384.887748796755,358296.0214553905,140661.4380856066,456959.9690822229,115509.8972636278,551852.1442379927,263965.23587302887,595812.4921183779,264883.22682543105,380702.99609763426,238048.54530185566,236013.44861746818
method = weighted lowest altitudes
radars = JAB,NL60,NL61,emd,ess,nhb
ranges = 298.75,239.5,239.5,127.5,127.5,127.5
timestamp_first_composite = 20151211080000
timestamp_last_composite = 20151212075500

map_projection (6024, 2)
Group size = 0
Number of attributes = 3
projection_indication = Y
projection_name = STEREOGRAPHIC
projection_proj4_params = +proj=sterea +lat_0=52.15616055555555 +lon_0=5.38763888888889 +k=0.999908 +x_0=155000 +y_0=463000 +ellps=bessel +towgs84=565.237,50.0087,465.658,-0.406857,0.350733,-1.87035,4.0812 +units=m +no_defs

geographic (5200, 2)
Group size = 1
Number of attributes = 8
geo_dim_pixel = KM,KM
geo_number_columns = 500
geo_number_rows = 490
geo_par_pixel = X,Y
geo_pixel_def = CENTRE
geo_pixel_size_x = 1.0
geo_pixel_size_y = -1.0
geo_product_corners = -110000,210000,-110000,700000,390000,700000,390000,210000

Right now I am using a complex code to rewrite each of the pixels to lat/lon & I plot them with matplotlib (python) on a mpl basemap without landcontours, coast-contours so I have an image on an mpl-basemap, but as said, without the countrycontours & such. The projecction used for the Basemap is "mercator". The result gives the desired radarimage & seems to match the locations... so far so good but with the python mapping of pixels to lat/lons...

I then run the output (a png file) through gdal to tile it, & warp it to the EPSG 3857 projection (Gmaps). When turning on the country-contours to check the result, the result is not correct, although it comes close to what it should be.

http://postimg.org/image/ly01obb1n/

I am starting to wonder if there's another way I can make this work, perhaps without the use of matplotlib python? Eg, going from the standard x-y grid Hdf5 data straight to a warp using gdal or whichever way possible. I have run out of ideas & the information I can find to help me get passed this is really confusing.


I am looking forward to the reply of the masters in this forum.


Best regards

D.
_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj
Micah Cochran | 31 May 20:49 2016
Picon

Changing Math Constants

This is my attempt to put the math constants into M_ namespace, and when possible use the compiler to define those constants.

I opened  PR #387
https://github.com/OSGeo/proj.4/pull/387

This is similar to an earlier PR that I had opened.

So, I'm looking for any comments about this change.

Thank you,
Micah
--

Micah Cochran

GIS Coordinator  -  City of Athens  -  Engineering Services & Community Development Dept.  -  Dept. of Public Works Building  -  1600 ELM ST W, Athens, AL  - geo:34.820608,-86.991474 -  p. 256-233-2224  -  f. 256-233-8791 - www.athensalabama.us  

_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj
Wang Leslie | 25 May 00:30 2016
Picon

which Cylindrical projection has smallest area

Dear all,


https://en.wikipedia.org/wiki/List_of_map_projections#Table_of_projections lists so many different Cylindrical projection. I guess different projection should generate different dimensions. If yes, can you please tell me which one has smallest area (width multiply height)? And also how about 1) Guyou hemisphere-in-a-square projection; 2) Adams hemisphere-in-a-square projection; 3) Eckert II, which are not Cylindrical projection, but still have polygon shape. 


Best Regards

Leslie

_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj
Even Rouault | 24 May 00:49 2016

Performance impact of switch of utm to etmerc

Hi,

I've given a try with proj master with GDAL, and wanted to assess the 
performance impact of utm now using etmerc instead of tmerc.

Given a in.tif raster of 5000x5000 pixels in EPSG:3857, I did :

$ time gdalwarp in.tif out.tif  -t_srs EPSG:32611 -overwrite -et 0 -q

This runs in 18.1 s. With proj 4.9.2, the same runs in 13.6 s

EPSG:32611 is resolved by GDAL as "+proj=utm +zone=11 +ellps=WGS84 +units=m 
+no_defs"

I added explicitly -et 0 so that the exact transformer of GDAL is used, 
meaning that 5042x5019 inverse projections will be done (number of pixels of 
output dataset). By default GDAL would use an approximate linear interpolation 
transformer leading to very few transformations, and the time spent in proj is 
then almost neglectable. But with -et 0, reprojection work becomes really 
significant. It should be noted that -et 0 is the default if doing RPC 
transformation with a DEM since GDAL 2.1.0 (since DEM have no nice regularity, 
an approximate interpolator can do really bad guesses in mountain areas), and 
this will probably the use case mostly affected by this.

To come back to previous performance, I've added in GDAL the possibility to 
define the OSR_USE_ETMERC=NO configuration option/environment variable so that 
"+proj=utm" is expanded to the appropriate "+proj=tmerc ...."

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

Wang Leslie | 23 May 16:31 2016
Picon

convert from Equidistant Cylindrical to Eckert I

Dear all,


I'm new to this tool, and hope to get some advise here.

I'm thinking to use your tool to convert a map picture which is based on Equidistant Cylindrical, to another picture based on Eckert I. Since both of them are 2 dimension only (x,y), what I'm gonna to do is:
 - Use proj command to calculate the new mapped coordinate (x1, y1)
 - Set new pixel value at (x1, y1) using original pixel value (x,y)
 - loop for all pixel at original Equidistant Cylindrical picture

So can you please help me confirm if one idea can work or not? If yes, what should command line look like? Thanks.

Best Regards
Leslie Qi Wang
_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj
Thomas Knudsen | 20 May 19:48 2016
Picon

Re: Motion: add Kristian Evers and Thomas Knudsen to the Proj.4 team

Janne,


First, I strongly object to being characterized as a “random rewriter”.


I have used proj since 1993, did my first (tiny) contribution to the code base in 1999, and I facilitated the inclusion of the etmerc, high precision transverse mercator code written by my colleague Karsten Engsager, in 2008.


It is correct that I have not touched the code base since then, but that does not turn me into a “random rewriter”.


Also, I described my intended work, and asked for comments and opinions on the proj mailing list more than a month ago. It attracted one comment, which was very much in favor of the work. It did not attract any comments from you.


Also, the pull request has been open since the beginning of april. Howard Butler, Even Rouault, and Micah Cochran have commented and given constructive criticism. I have seen no comments from you.


So all in all, you have had plenty of time to air your opinion. It would have been very helpful if you had done it a bit earlier than 2 months into the process. As a long term proj-list member, I know that you are a frequent and very helpful list contributor, so I have great respect for your experience and willingness to share it, and I believe you could have been a very helpful commenter and mentor for this work.



Second: In general I agree with your opinion of “not touching what works”.


However, what “works” is not easily definable - especially not in the long term.


Kristian Evers and I have turned to proj after having spent time updating trlib, the transformation system of the Danish national mapping agency (now SDFE, formerly GST, formerly KMS, formerly GI).


trlib originated as Algol code written around 1961, for the GIER system (a, for that time, medium sized computer, which was highly optimized for geodetic computations). The code survived and evolved through more than 5 decades following what was “current best practice” all along.


And the one “best practice” that has been prevalent through all these decades has been exactly the one you forward here.


The problem is that, while commendable for the medium term, for the long term “not touching what works” leads to kludge-upon-kludge, from bolting on additional functionality, while not touching existing code.


In the long term, the “not touching what works” dogma (NTWW in the following) leads to stale and unmaintainable code.


As an example, for trlib, one of the things we have removed during the last few years of code revision, is a complete user-space Virtual Menory mangagement system. It was evidently needed when added to the code around 1970, and left in due to NTWW when the code was migrated from Algol to C around 1980. And kept ever since, due to NTWW.


So our experience is very much that NTWW should be challenged now and then. Things change, and so do the hardware platforms the code is supposed to run on.


The proj.4 macro system reflects a development environment of Tektronix style, green phosphor 24x80 terminals, where saving vertical whitespace directly translated into a better general view, by having more context on screen at a time.


This is not the problem for modern coding tools on modern high-resolution displays. In today’s coding environment the proj internal macro system is a high barrier for entry: It makes it extremely hard for new coders to get productive.


If you look at the commit history, you will notice that new people enter the project in order to contribute one or two new projectione that they need.


They do not stay to help evolving proj further. I hypothesize that this is at least partially because the macro system is convoluted and not at all C-like (e.g. leading to syntax highlighter blues).


My intention was to make the code less impenetrable, in order to make it more welcoming to new contributors. As you will see when you study the code, this has been done without touching the algorithmic flow. The procedure has been designed to enhance the clarity for human readers - not to touch the flow.


I suggest you read the description “A verbose justification for some highly intrusive code surgery” I wrote at the very beginning of this work, over at https://github.com/busstoptaktik/proj.4/blob/sdfe-refactor-macros--and-repair-generic-constructor-bug/src/PJ_minimal.c. Hopefully you will see that I have no intentions to break what works - but at medium time scale intervals, changing what works is necessary in order to keep things in shape.


regards

Thomas


_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj
Howard Butler | 20 May 15:50 2016
Picon

Motion: add Kristian Evers and Thomas Knudsen to the Proj.4 team

All,

I propose to add Thomas Knudsen and Kristian Evers to the Proj.4 team with commit rights into the
OSGeo/Proj.4 repository. They have been leading a modernization effort in the Proj.4 package to improve
maintainability, reduce redundancy, and increase test coverage. Thomas has also been a long time Proj.4
list member, and he has provided a lot of experience and guidance on a number of coordinate system and
projection topics. Both have been software contributors in a project that has been lacking them, and
giving them full access will make it more convenient for them to contribute.

I'll start with a +1.

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

Finn, Michael | 19 May 17:06 2016
Picon

Call for Lightning Talks -- Workshop of Open Source Geospatial Technologies

Call for Lightning Talks


Workshop of Open Source Geospatial Technologies

 

At AutoCarto 2016, Albuquerque, New Mexico, USA

14 September 2016

 

The ICA Commission on Open Source Geospatial Technologies is holding a one-day workshop on “Advancing GIScience with Open Source Technologies.” AutoCarto 2016 will be held in Albuquerque, New Mexico, USA, 14 – 16 September 2016 (http://tinyurl.com/p7bpfhp).

 

This workshop at AutoCarto 2016 is a follow-on to the successful AutoCarto 2012 workshop on "The Internet and Geospatial Technologies,” (Columbus, Ohio).  AutoCarto is a Cartography and Geographic Information Society (CaGIS) research symposium held every two years. CaGIS is the US adhering body to the International Cartographic Association (ICA).

 

In the morning, invited speakers will give presentations on the workshop topic. In the afternoon, we will have a series of lightning talks. These talks will quickly and broadly introduce recent trends and identify future research possibilities in the rapidly expanding domain of open source technologies in the GIScience domain. Further, these talks will identify existing and new researchers and practitioners in the field and open up new collaboration opportunities. Ultimately, these talks and the workshop, as a whole, will provide attendees (and their research or development teams) with a platform for discussing the dramatically changing open source landscape.

 

 

Please provide a proposed talk title (and, if you would like, an expanding sentence or two) and your contact information to:

 

Michael P. Finn

U. S. Geological Survey

Vice-Chair, ICA Commission on Open Source Geospatial Technologies

mfinn <at> usgs.gov

 

 Important Dates:

Proposed Talk Title Submission: 20 June 2016

Acceptance Decision Notification to Submitters: 15 July 2016

Early Registration Deadline: 01 August 2016

Registration: http://tinyurl.com/zl8dadg

n  Note: Attendees must be registered for AutoCarto 2016. There is no separate or addition fee for the workshop

Lightning Talks: 14 September 2016

 

 

_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj
Howard Butler | 19 May 16:12 2016
Picon

MACRO modernization

All,

I just wanted to make you aware of the significant effort that Thomas Knudsen and Kristian Evers have put in
to modernize Proj.4's macros and codebase. Along the way, they've increased the code coverage 42%!

Three cheers to them!

https://github.com/OSGeo/proj.4/pull/373

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


Gmane