gmane.comp.gis.gdal.devel

Re: troubles with OVERRIDE_PROJ_DATUM_WITH_TOWGS84

Francesco P. Lovergine — 2012-05-23T08:45:25

I would also add that changing any EPSG (non custom) code description (e.g. by assuming
a datum whenever it is not assumed for any official code) could be possibly 
seen as a license violation (point 2 of the license). At least it seems a 
bit strange assuming a datum when no datum is specified on purpose as in many codes. 
Of course IMHO and IANAL.

Re: troubles with OVERRIDE_PROJ_DATUM_WITH_TOWGS84

G. Allegri — 2012-05-22T22:47:13

No Frank, that would be a hell! :)
I was just thinking about the relation that can be assumed between the
epsg strings produced by gdal and the epsg codes from the EPSG
registry. I mean, if I say that I'm using an EPSG:3003, it's different
if I assume it in its original definition (without transformation
parameters) and the one produced by gdal (with a best available
transformation).
For anything custom I would strictly use the rule of using code ranges
beyon 32767, and to avoid clashes an authority field would help.



I was referring to the extended -t_srs option you were suggesting...

giovanni

Re: troubles with OVERRIDE_PROJ_DATUM_WITH_TOWGS84

Frank Warmerdam — 2012-05-22T22:38:22

Giovanni,

I'm afraid I don't really follow your point.  Are you wanting to
be able to do something like -t_srs GFOSSIT:3033 ?

Note that you can register coordinate systems with
spatialreference.org and then use those urls with GDAL/OGR
tools if you want something customized.

Keep in mind that some OGC web services are not going
to support such mechanisms in an interoperable way.


I'm not too sure if your misspelling is intentional or not,
though it captures how I often feel about datums.

Best regards,

Re: troubles with OVERRIDE_PROJ_DATUM_WITH_TOWGS84

G. Allegri — 2012-05-22T22:31:17

Frank,
I think the opposite. Maybe it's useful for users (even if I think
it's dangerous and should be avoided) to suggest an approximate
transformation, but for services the tranformation should be chosen
carefully and shouldn't assume a default one when a correct default
isn't available.

One proposals come from the GFOSS.it community is to consider a couple
of new fields to characterize the epsg code: an authority code, and
maybe an internal id for each CRS.
Having "official" EPSG codes following the EPSG Registry would keep
Proj4 consitent with a standard de facto. Then we could have other
"gdal", "gfoss.it", etc. codes derived from the offical EPSG but with
custom adjustments, like local transformations or whatelse.
Would it be technically difficult, while maintaining
retrocompatibility to let applications adopt it or not?

In the meanwhile I will ask the GFOSS.it community to consider the
opportunity to add a datum_shift_pref.csv row.

The idea of a DATUMSHIT selector would be nice ;)
giovanni

2012/5/22 Frank Warmerdam <warmerdam< at >pobox.com>:

Re: troubles with OVERRIDE_PROJ_DATUM_WITH_TOWGS84

Frank Warmerdam — 2012-05-22T21:38:38

Giovanni,

It is desirable for users to be able to select or at least override
the transformation.  But for automation of interactions with a
variety of services it is not appropriate to have to do that all the
time.

One thing I'd like to do is extend gdalsrsinfo to report a list of
potential datum shift operations available for the datum of a
given SRS, and some syntax to override the datum shift
operation when doing EPSG look ups.  For instance from
gdal/data/datum_shift.csv I see EPSG:4265 (Monte Mario)
has the following datum transformations possible:

422,1088,4265,4326,,Oil exploration and
production,2882,43,47.25,12,19.5,1,0,9603,-223.7,-67.38,1.34,,,,,0
423,1089,4265,4326,,Oil exploration and
production,2883,41.75,43.75,13.25,19,1,0,9603,-225.4,-67.7,7.85,,,,,0
424,1090,4265,4326,,Oil exploration and
production,2884,39.75,42,16,20,1,0,9603,-227.1,-68.1,14.4,,,,,0
425,1091,4265,4326,,Marine
navigation,2885,39.5,41,18,20,1,0,9603,-231.61,-68.21,13.93,,,,,0
426,1092,4265,4326,,Marine
navigation,2886,37,40.5,16,21,1,0,9603,-225.06,-67.37,14.61,,,,,0
427,1093,4265,4326,,Marine
navigation,2887,36,37.5,13,16,1,0,9603,-229.08,-65.73,20.21,,,,,0
428,1094,4265,4326,,Marine
navigation,2888,36.5,38.5,10,13,1,0,9603,-230.47,-56.08,22.43,,,,,0
429,1169,4265,4326,Derived at 1 station.,For military purposes.
Accuracy 25m in each
axis.,2339,38.5,41.5,8,10,1,0,9603,-225,-65,9,,,,,0
430,1660,4265,4326,"Parameter values from Monte Mario to ETRS89 (1)
(code 1659). Assumes ETRS89 and WGS 84 can be considered the same to
within the accuracy of the transformation.","Accuracy: 4
metres",2372,37.75,47.09,6.65,18.53,1,0,9606,-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68,1
431,1662,4265,4326,"Parameter values from Monte Mario to ETRS89 (2)
(code 1661). Assumes ETRS89 and WGS 84 can be considered the same to
within the accuracy of the transformation.","Accuracy: 4
metres",2339,38.5,41.5,8,10,1,0,9606,-168.6,-34,38.6,-0.374,-0.679,-1.379,-9.48,0
432,1664,4265,4326,"Parameter values from Monte Mario to ETRS89 (3)
(code 1663). Assumes ETRS89 and WGS 84 can be considered the same to
within the accuracy of the transformation.","Accuracy: 4
metres",2340,36.5,38.5,12,16,1,0,9606,-50.2,-50.4,84.8,-0.69,-2.012,0.459,-28.08,0

It would be nice to be able to use a parameter like:

-t_srs EPSG:3003/DATUMSHIFT:1662

in order to use the 3003 coordinate system but force selection
of the 1662 datum shift operation.

Perhaps now is a reasonable time for us to pursue this...

Best regards,

Re: troubles with OVERRIDE_PROJ_DATUM_WITH_TOWGS84

G. Allegri — 2012-05-22T21:25:33

Thanks Frank for the clear explanation. I've missed your blog post.
I think that the rational behind the sorting logic is the best that
can be done if a choice must be made. The point is IF that choice
should be made, and you give lot of reasons for it, and I suppose lot
of users agree with having a default transformation. In general I
think that transformation parameters shouldn't be provided as part of
a CRS definition, but I suppose I'm not part of the majority of the
users :)

giovanni



2012/5/22 Frank Warmerdam <warmerdam< at >pobox.com>:

GDAL/OGR 1.9.1 Released

Frank Warmerdam — 2012-05-22T21:18:01

On behalf of the GDAL/OGR development team, I am pleased to
announce the release of the GDAL/OGR 1.9.1 bug fix release.  This
release contains many bug fixes since the December 1.9.0 release.

The source is available at:

  http://download.osgeo.org/gdal/gdal191.zip
  http://download.osgeo.org/gdal/gdal-1.9.1.tar.gz

Details on the the fixes in this release are available at:
  http://trac.osgeo.org/gdal/wiki/Release/1.9.1-News

Best regards,

Re: troubles with OVERRIDE_PROJ_DATUM_WITH_TOWGS84

Frank Warmerdam — 2012-05-22T20:58:56

Giovanni,

The logic for deciding which available datum shift to use as
preferred is embedded in:

  http://svn.osgeo.org/metacrs/geotiff/trunk/libgeotiff/csv/build_pcs.py

The logic around setting pref_rec and preferred_op is the key.

Skimming the logic it:
 * Prefers the transformation with the largest area of use.
 * avoids deprecated transformations.
 * avoids records that have been superceeded.

I believe I discuss the topic in:

http://fwarmerdam.blogspot.com/2010/03/in-last-few-weeks-i-believe-i-have-made.html

There is the possibility of pre-setting a preferred datum transformation in:

    http://svn.osgeo.org/metacrs/geotiff/trunk/libgeotiff/csv/datum_shift_pref.csv

If you feel there is a more appropriate set of shift parameters to use
for the datum in question, please file a ticket (ideally against libgeotiff)
with a justification I can reference when I add it in the file.  Hopefully
a reasonably convincing explanation.

Also, please understand that no set of shift values is ideal and I
prefer something broadly reasonable to something that is super
in one local region and very poor in another where the datum is
used.   The "largest area of use" rule of thumb is intended to
select on this basis.

Best regards,

Re: troubles with OVERRIDE_PROJ_DATUM_WITH_TOWGS84

G. Allegri — 2012-05-22T20:47:56

Hi Even,
I have some difficults to follow the overall flow controlling the
peaking of the preferred transformation. What is the general rational
that define a transformation considered "preferred"?
In the case reported by Maddalena, the chosen transformation
parameters are (approximately) good for central Italy, while they are
not well suited for other regions of our country. In our case they're
"preferred" only by some italians :)

Giovanni

Re: Motion: Promote GDAL 1.9.1RC2 to Final Release

Frank Warmerdam — 2012-05-22T20:37:38

Folks,

I declare this motion passed with support from Frank, Daniel, Even and Tamas.
I'll rename the RC to final and update the news page.

Thanks for the prompt Jeff!

Best regards,

Re: Motion: Promote GDAL 1.9.1RC2 to Final Release

Jeff McKenna — 2012-05-22T20:25:06

Did this motion pass?  I notice that the 1.9.1 news page does not exist
on trac.osgeo.org/gdal/

-jeff

Re: troubles with OVERRIDE_PROJ_DATUM_WITH_TOWGS84

Even Rouault — 2012-05-22T19:25:27

Le mardi 22 mai 2012 21:01:26, Margherita Di Leo a écrit :

 --config OVERRIDE_PROJ_DATUM_WITH_TOWGS84 FALSE definitely works. I've just 
verified it, and I see that the epsg file delivered with proj 4.8.0 takes into 
account http://trac.osgeo.org/proj/changeset/2172 . The effect of that is just 
to avoid expanding +datum definitions.

Your issue with EPSG:3003 is of a different kind, and related to another change 
where the new logic now peaks up the EPSG preferred transformation whereas it 
didn't before. I think this is related to 
http://trac.osgeo.org/geotiff/changeset/1819/ and 
http://trac.osgeo.org/geotiff/changeset/1829/

troubles with OVERRIDE_PROJ_DATUM_WITH_TOWGS84

Margherita Di Leo — 2012-05-22T19:01:26

Hi folks,

looks like this bug ticket [1] finds its roots into the gdal code. From a
discussion [2] in the gfoss.it [3] ML (the italian OSGeo local chapter)
emerged that gdal 1.8.0 introduced a further option named
OVERRIDE_PROJ_DATUM_WITH_TOWGS84, allowing to replace the +datum definition
with a corresponding +towgs84.
Such option is not supposed to be the default behavior when generating the
standard EPSG file for Proj4:

epsg_tr.py --config OVERRIDE_PROJ_DATUM_WITH_TOWGS84 FALSE -proj4 -skip
-list gcs.csv > epsg

Anyway, from direct testing emerged that setting the above mentioned option
to YES, NO, TRUE or FALSE has absolutely no effect at all; the +datum
definitions are unconditionally overwritten by +towgs84 in all cases. And,
accordindgly to this, the EPSG file distributed by the most recent Proj4
4.8.0 introduces many unexpected changes (e.g. affecting the Italian Rome
1940 SRS), thus causing many troubles due to this abrupt compatibility
break.

Could anyone please verify that, and, in case, I'll open a ticket.
Thanks!

madi


[1] http://trac.osgeo.org/proj/ticket/122
[2] http://lists.gfoss.it/pipermail/gfoss/2012-May/023071.html
[3] www.gfoss.it

Re: [gdal-dev] Policy for C/C++ API for GDAL 2.0 ?

Ivan Lucena — 2012-05-22T10:11:47

Frank,


By integrating GDAL/OGR drivers into GDALDataset, I would imagine that we are going to be able to do things like 
using *gdalinfo* on a shapefile, for example. That could represent some changes in command line utilities.

Regards,

Ivan

Re: Policy for C/C++ API for GDAL 2.0 ?

Frank Warmerdam — 2012-05-22T02:30:47

On Sun, May 20, 2012 at 10:23 AM, Even Rouault
<even.rouault< at >mines-paris.org> wrote:

Even,

My brief thoughts are:

 * My objectives for GDAL/OGR 2.0 primarily revolve around
restructuring OGR to be close alignment with the GDAL API.  That means
moving to a unified driver model, and GDAL style creation option and
capabilities mechanisms.  I want to end up with a GDALDataset that can
have vector layers as well as bands.

 * To that end, I imagine non-trivial changes in the OGRDriver,
OGRDataSource and OGRLayer classes which will non-trivially their API.
 OGRFeature and OGRGeometry will hopefully not be very adversely
affected.

 * My goal then is to minimize disruption in the GDAL C++ API, and C
API with the C API hopefully being nearly entirely backward compatible
while the OGR C++ and C API will be signifcantly disrupted though I'm
hoping via some aliasing mechanisms we might be able to provide some
amount of compatability.

 * I hadn't considered big changes in the utilities myself but if ever
it was to be done now would be the time.

Best regards,
Frank

Re: Policy for C/C++ API for GDAL 2.0 ?

Even Rouault — 2012-05-21T19:50:04

I think that the justification of the 2.0 in GDAL 2.0 should be mostly drived 
by the need of implementing new real world functionnality that cannot be 
solved with GDAL 1.X. Personnaly, I think that the reorganization of header 
files, const-correctness changes, or other changes only justified to make things 
look cleaner internally are bonus, but should not be the main motivation.


Yes I agree that there's no reason to ditch out the existing C API. I'm not 
sure to understand how you would see the 2 API coexisting though. Would that 
be 2 libraries (like a libgdal1capi.so with its own include files and 
libgdal2capi.so with its own include files, that would both link to a 
libgdalc++.so) ?


The reason for initiating this discussion was to know which constraints we 
should impose on yourselves, a priori. It does not imply that major breaking 
changes will actually occur (at that time, I have no idea of what they could 
be anyway). I'm not sure there's the manpower and/or justification to make 
breaking changes happen. Let be realistic : given the large numbers of 
existing drivers, changing even internal interfaces might have prohibitive 
costs that can refrain enthousiasm.


Thinking out loud (half-convinced myself, but oh well, I take the risk to 
share even half-baked ideas) :

Looking at http://trac.osgeo.org/gdal/wiki/GDAL20Changes , I'm also wondering 
if 2.0 should not be the time to anticipate for later possible evolutions, and 
do the change in the API that would be needed, but not actually implement them 
if time does not permit it. For example, add progress callback arguments in 
some places, or add char** papszOptions as a provision for later extensions, 
or extend OGRField structure to add sub-second accuarcy (well, a wiser 
decision might be to just hide this structure from the public API !), or 
increase to 64bit data types some parameters. Or, for example, for  
http://trac.osgeo.org/gdal/wiki/rfc31_ogr_64, just do the API evolutions even 
if no drivers actually use them yet (but that's going to be frustrating !)

RFC31 is an interesting case actually when thinking again about the above idea 
of 2 versionso of the C API, one of them being the compatibility layer for 
GDAL 1. If we add a OFTInteger64 data type, even users of the old C API could 
have to deal with that data type as soon as drivers will use them. But not 
having any of the new API to deal with that 64bit data type, they will be 
stuck.

Best regards,

Even

RE: Microsoft VS 2010 - build of GDAL 1.9 does not work

Martin Chapman — 2012-05-21T18:01:09

You should be linking against gdal_i.lib.

Marty

-----Original Message-----
From: gdal-dev-bounces< at >lists.osgeo.org 
[mailto:gdal-dev-bounces< at >lists.osgeo.org] On Behalf Of James Farrell
Sent: Monday, May 21, 2012 9:23 AM
To: Mateusz Loskot
Cc: gdal-dev< at >lists.osgeo.org
Subject: RE: [gdal-dev] Microsoft VS 2010 - build of GDAL 1.9 does not work

Thanks, Mateusz
I see the source code now.  I'm linking against gdal.lib.  Shouldn't 
CPLStringLists's functions be in that library?  Did I somehow build it 
incorrectly?

Thanks again!
James

-----Original Message-----
From: gdal-dev-bounces< at >lists.osgeo.org 
[mailto:gdal-dev-bounces< at >lists.osgeo.org] On Behalf Of Mateusz Loskot
Sent: Monday, May 21, 2012 11:10 AM
To: James Farrell
Cc: gdal-dev< at >lists.osgeo.org
Subject: Re: [gdal-dev] Microsoft VS 2010 - build of GDAL 1.9 does not work

On 21 May 2012 15:41, James Farrell <James.Farrell< at >delorme.com> wrote:

Look at port/cplstringlist.cpp

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net 
_______________________________________________
gdal-dev mailing list
gdal-dev< at >lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: Policy for C/C++ API for GDAL 2.0 ?

Homme Zwaagstra — 2012-05-21T15:47:30

I'd also love to see some normalisation of the utilities' help, naming
and calling conventions. In an ideal world (!) I think the git and svn
commands provide a great pattern of use: one 'master' executable
providing access to various 'subcommands'. For GDAL this might be
along these lines:

  /usr/bin/gdal_translate -of JPEG src.tiff dst.jpg
  -->
  /usr/bin/gdal translate -of JPEG src.tiff dst.jpg

  /usr/bin/gdalwarp -t_srs '+proj=utm +zone=11 +datum=WGS84' raw_spot.tif utm11.tif
  -->
  /usr/bin/gdal warp -t_srs '+proj=utm +zone=11 +datum=WGS84' raw_spot.tif utm11.tif

The advantage here is that there is a unified hierarchical commandline
interface to all the gdal functionality which is also extensible in
terms of adding new commands and options.

The 'gdal' master executable could also accept options that are
globally applicable to all subcommands e.g.:

  /usr/bin/gdal -quiet subcommand -options

It looks like GNU `argp_parse` could help build such an interface, or
at least provide a reference:
http://www.gnu.org/software/libc/manual/html_node/Argp.html#Argp

Using this paradigm there might need to be a separate `gdal.py` along
similar lines to a binary `/usr/bin/gdal` in order to take care of the
python based utilities. The `argparse` module could be helpful here:
http://pypi.python.org/pypi/argparse

In terms of implementing this with minimal disruption the above could
be something as simple as a wrapper to existing utilities, easing the
migration for users and developers alike.

Alternatively the existing utilities could be 'frozen' whilst new
development takes place within new utilities (whichever new naming
convention is chosen). A configure option (--disable-gdal1?) could
determine whether the gdal1 utilities are installed on the system.

Best regards,

Homme

RE: Microsoft VS 2010 - build of GDAL 1.9 does not work

James Farrell — 2012-05-21T15:37:45

Oops
This company (to which I am new) keeps multiple copies of the library in multiple folders.  I rather assumed we were linking against the ones in the gdal folder, but I was wrong.  Needed to update the library in a different folder and it worked.

Thanks for your help
James

-----Original Message-----
From: Mateusz Loskot [mailto:mateusz< at >loskot.net] 
Sent: Monday, May 21, 2012 11:30 AM
To: James Farrell
Cc: gdal-dev< at >lists.osgeo.org
Subject: Re: [gdal-dev] Microsoft VS 2010 - build of GDAL 1.9 does not work

On 21 May 2012 16:23, James Farrell <James.Farrell< at >delorme.com> wrote:

CPLStringLists is exported function.
AFAIK, it should be visible without any extra steps.

Best regards,

RE: Microsoft VS 2010 - build of GDAL 1.9 does not work

James Farrell — 2012-05-21T15:23:05

Thanks, Mateusz
I see the source code now.  I'm linking against gdal.lib.  Shouldn't CPLStringLists's functions be in that library?  Did I somehow build it incorrectly?

Thanks again!
James

-----Original Message-----
From: gdal-dev-bounces< at >lists.osgeo.org [mailto:gdal-dev-bounces< at >lists.osgeo.org] On Behalf Of Mateusz Loskot
Sent: Monday, May 21, 2012 11:10 AM
To: James Farrell
Cc: gdal-dev< at >lists.osgeo.org
Subject: Re: [gdal-dev] Microsoft VS 2010 - build of GDAL 1.9 does not work

On 21 May 2012 15:41, James Farrell <James.Farrell< at >delorme.com> wrote:

Look at port/cplstringlist.cpp

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net _______________________________________________
gdal-dev mailing list
gdal-dev< at >lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

_______________________________________________
gdal-dev mailing list
gdal-dev< at >lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: Microsoft VS 2010 - build of GDAL 1.9 does not work

Mateusz Loskot — 2012-05-21T15:30:22

CPLStringLists is exported function.
AFAIK, it should be visible without any extra steps.

Best regards,