date:20140125

Re: [gdal-dev] gdaldem slope with -s 111120.0 works only at equator for lat/lon?

2014-01-25 Thread Even Rouault

Le samedi 25 janvier 2014 00:47:45, John Abraham a écrit :
 Here’s a diff on the .dox for gdaldem, as a suggestion. 

Applied, thanks.

 (I don’t want
 commit access on the repository.  Is sending the diff by email the
 appropriate approach?)

For very short patches such as that one, it is OK. Otherwise it is better to 
put it as an attachment in http://trac.osgeo.org/gdal/newticket

-- 
Geospatial professional services
http://even.rouault.free.fr/services.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Extra Decimal places added to ASCII gdal_translate mosaic

2014-01-25 Thread Even Rouault

Le vendredi 24 janvier 2014 23:03:24, Hermann Peifer a écrit :
 On 2014-01-24 17:22, Norman Vine wrote:
  hmm
  
  this seems to be related to this fairly recent change
  http://trac.osgeo.org/gdal/ticket/3732
  http://osgeo-org.1560.x6.nabble.com/gdal-dev-Change-of-DECIMAL-PRECISION-
  in-AAIGrid-td5075524.html
 
 I am just repeating what I wrote in the above-mentioned mail from 3 Sep
 2013:
 
 --- snip ---
 DECIMAL_PRECISION  actually became a misnomer now and should perhaps
 be called SIGNIFICANT_DIGITS -- or the format should be changed back
 to %precisionf. Maybe some of the GDAL devs has an opinion about the
 issue.
 --- snip ---

Yes reverting to the original implementation of DECIMAL_PRECISION could be 
usefull. And maybe keeping the current behaviour under a SIGNIFICANT_DIGITS 
option ?
Anyone wanting to patch that ?

CC'ing Robert to get his opinion on this.

 Hermann
 
 ___
 gdal-dev mailing list
 gdal-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
Geospatial professional services
http://even.rouault.free.fr/services.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Problem calling gdalwarp from within python script

2014-01-25 Thread Simon Richard Proud

Hi,
I can't see any rational reason for that... Just in case : are you sure you
are running the same GDAL lib and binary in the terminal and from Python ?

Yes, there's only one GDAL lib installed on the system - the default one that 
can be installed from the Ubuntu package manager.

Anyway, I changed to use the internal gdal.ReprojectImage() commands (rather 
than calling gdalwarp) and those work well. So from my perspective there is no 
problem, although it'd be nice to know what happened in gdalwarp!

Cheers,
Simon


Fra: Even Rouault [even.roua...@mines-paris.org]
Sendt: 24. januar 2014 16:17
Til: gdal-dev@lists.osgeo.org
Cc: Simon Richard Proud; Sean Gillies
Emne: Re: [gdal-dev] Problem calling gdalwarp from within python script

Le vendredi 24 janvier 2014 21:46:50, Simon Richard Proud a écrit :
 Does anyone have any other ideas as to what would be causing gdalwarp to
 output entire blank images when called from a python script? I can get it
 to run using os.system and subprocess.call (using both shell=True and
 shell=False) but always just get a blank image (all pixels=0). This does
 not happen if I run exactly the same command from a terminal window.

I can't see any rational reason for that... Just in case : are you sure you
are running the same GDAL lib and binary in the terminal and from Python ?


 Thanks,
 Simon

 
 Fra: gdal-dev-boun...@lists.osgeo.org [gdal-dev-boun...@lists.osgeo.org]
 p#229; vegne af Sean Gillies [s...@mapbox.com] Sendt: 20. januar 2014
 11:56
 Til: gdal-dev@lists.osgeo.org
 Emne: Re: [gdal-dev] Problem calling gdalwarp from within python script

 On 1/20/14, 1:57 AM, Even Rouault wrote:
  Selon Simon Richard Proud s...@geo.ku.dk:
  Hi,
  Unfortunately that produces a file not found error with filename
  65535. If I remove both arguments -srcnodata and 65535 then I go
  back to getting the usage guidelines.
 
  You need to separate also the numerical values after -te and -tr
 
  ['gdalwarp','-q','-multi','-r', 'cubicspline','-t_srs', '+proj=geos
  +lon_0=0.0 +h=35785831', '-te', '-5568748.2758', '-5568748.4774',
  '5568748.2758', '5568748.2758','-tr', '3000.40316582', '3000.40316582',
  '-srcnodata', '65535','TEST.tiff', 'TEST2.tiff']

 The shlex.split() function is handy for turning strings that you would
 have passed to os.system() into a list of args for subprocess functions.

   import shlex
   shlex.split('gdalwarp -q -multi -r cubicspline -te

 -5568748.2758 -5568748.4774 5568748.2758 5568748.2758')
  ['gdalwarp', '-q', '-multi', '-r', 'cubicspline', '-te',
 '-5568748.2758', '-5568748.4774', '5568748.2758', '5568748.2758']

 ...

 --
 Sean Gillies
 s...@mapbox.com
 ___
 gdal-dev mailing list
 gdal-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/gdal-dev


 ___
 gdal-dev mailing list
 gdal-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/gdal-dev

--
Geospatial professional services
http://even.rouault.free.fr/services.html


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] New option INDEX_COLUMNS for SQLite and GPKG

2014-01-25 Thread Jukka Rahkonen

Hi,

I guess that both SQLite/Spatialite and especially OGC Geopackage will be
used by people who consider them more like file formats than as datebases.
Such users may not know the power of indexes and they do not necessarily
know anything about SQL and such.

How about writing a few lines about the power and importance of indexes into
the SQLite and GPKG driver pages? There could at least be on example about
how to create a new index with ogrinfo, which must be a secret even for many
advanced GDAL users. Better though, from user point of view, would be to
implement a new layer creation option. I see a very similar case in
SQLite/Spatialite
COMPRESS_COLUMNS=column_name1[,column_name2, ...]: (Starting with GDAL
1.10.0) A list of (String) columns that must be compressed
The new -lco might be
INDEX_COLUMNS=column_name1[,column_name2, ...]: (Starting with GDAL 2.0) A
list of columns that will be indexed.

I am not sure if -lco should somehow support also composite indexes. Perhaps
users who know what those (and unique indexes) mean can also use SQL and
create them with ogrinfo if they can see an example in the documentation.
Thus -lco could be made to accept only one column per index. And index name
in the db could be set automatically into something like
layer_name_column_name_idx. The SQL that this -lco should fire is simply

CREATE INDEX table_name_column_name_idx
ON table_name (column_name);

-Jukka Rahkonen-

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] New option INDEX_COLUMNS for SQLite and GPKG

2014-01-25 Thread Even Rouault

Hi Jukka,

I'm a bit ambivalent about providing a creation option for that (although that 
would not be an heresy). For a few reasons :
- it is relatively easy to create an attribute index manually (once you know 
the syntax)
- it is not necessarily to create it at layer creation time
- it would potentially apply to all drivers that have a SQL engine behind

But I agree that improving the documentation to advertize the interest of 
indexes and how to create them could be usefull. Perhaps you would want to 
propose a modified version of the HTML page ? (I think that the GPKG one could 
just point to the relevant section of the SQLite one, to avoid doc 
duplication)

Even

 Hi,
 
 I guess that both SQLite/Spatialite and especially OGC Geopackage will be
 used by people who consider them more like file formats than as datebases.
 Such users may not know the power of indexes and they do not necessarily
 know anything about SQL and such.
 
 How about writing a few lines about the power and importance of indexes
 into the SQLite and GPKG driver pages? There could at least be on example
 about how to create a new index with ogrinfo, which must be a secret even
 for many advanced GDAL users. Better though, from user point of view,
 would be to implement a new layer creation option. I see a very similar
 case in SQLite/Spatialite
 COMPRESS_COLUMNS=column_name1[,column_name2, ...]: (Starting with GDAL
 1.10.0) A list of (String) columns that must be compressed
 The new -lco might be
 INDEX_COLUMNS=column_name1[,column_name2, ...]: (Starting with GDAL 2.0) A
 list of columns that will be indexed.
 
 I am not sure if -lco should somehow support also composite indexes.
 Perhaps users who know what those (and unique indexes) mean can also use
 SQL and create them with ogrinfo if they can see an example in the
 documentation. Thus -lco could be made to accept only one column per
 index. And index name in the db could be set automatically into something
 like
 layer_name_column_name_idx. The SQL that this -lco should fire is simply
 
 CREATE INDEX table_name_column_name_idx
 ON table_name (column_name);
 
 -Jukka Rahkonen-
 
 ___
 gdal-dev mailing list
 gdal-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
Geospatial professional services
http://even.rouault.free.fr/services.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] exportToProj4

2014-01-25 Thread Paul Meems

Hi all,

Thanks to Tamas Szekeres we are now using his binaries from
http://www.gisinternals.com/sdk/ with MapWinGIS, our mapping ActiveX.
This has drastically simplified our build process and we are very grateful
for Tamas' help.

We're now struggling with some minor issues regarding our 'old' C++ code
and the new binaries for GDAL, GEOS, Proj4, etc.
Several of them I managed to solve, but I'm struggling with this one.
We have code to read a prj file and get the Proj4 string:

void ProjectionTools::GetProj4FromPRJFile(char * prjfileName, char **
prj4)
{
FILE * pFile;
pFile = fopen (prjfileName,r);
if (pFile == NULL)
{
// Doesn't exist
return;
}
fclose(pFile);
pFile = NULL;
OGRSpatialReference* oSRS = new OGRSpatialReference();

char **papszPrj = CSLLoad(prjfileName);
if (papszPrj == NULL)
{
return;
}

OGRErr eErr = oSRS-importFromESRI(papszPrj);
if (eErr != OGRERR_NONE)
{
OGRErr eErr = oSRS-importFromProj4(*papszPrj);
}

CSLDestroy( papszPrj );
char * pszProj4 = NULL;
eErr = oSRS-exportToProj4( pszProj4 );
delete oSRS; -- going wrong now

*prj4 = new char[_tcslen(pszProj4)+1];
strcpy(*prj4, pszProj4);
CPLFree(pszProj4);
}

This code was working for years, but now it crashes on delete oSRS;.
I've been searching for examples of how to use exportToProj4() in C++ but
can only find Python examples.
And I'm not a C++ developer, just a C# developer :)
How should I now free oSRS?

Thanks for any advice.

Paul

*Paul Meems *
Release manager, configuration manager
and forum moderator of MapWindow GIS.
www.mapwindow.org

Owner of MapWindow.nl - Support for
Dutch speaking users.
www.mapwindow.nl
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] exportToProj4

2014-01-25 Thread Even Rouault

Le samedi 25 janvier 2014 23:50:10, Paul Meems a écrit :
 Hi all,
 
 Thanks to Tamas Szekeres we are now using his binaries from
 http://www.gisinternals.com/sdk/ with MapWinGIS, our mapping ActiveX.
 This has drastically simplified our build process and we are very grateful
 for Tamas' help.
 
 We're now struggling with some minor issues regarding our 'old' C++ code
 and the new binaries for GDAL, GEOS, Proj4, etc.
 Several of them I managed to solve, but I'm struggling with this one.
 We have code to read a prj file and get the Proj4 string:
 
 void ProjectionTools::GetProj4FromPRJFile(char * prjfileName, char **
 prj4)
 {
 FILE * pFile;
 pFile = fopen (prjfileName,r);
 if (pFile == NULL)
 {
 // Doesn't exist
 return;
 }
 fclose(pFile);
 pFile = NULL;
 OGRSpatialReference* oSRS = new OGRSpatialReference();
 
 char **papszPrj = CSLLoad(prjfileName);
 if (papszPrj == NULL)
 {
 return;
 }
 
 OGRErr eErr = oSRS-importFromESRI(papszPrj);
 if (eErr != OGRERR_NONE)
 {
 OGRErr eErr = oSRS-importFromProj4(*papszPrj);
 }
 
 CSLDestroy( papszPrj );
 char * pszProj4 = NULL;
 eErr = oSRS-exportToProj4( pszProj4 );
 delete oSRS; -- going wrong now
 
 *prj4 = new char[_tcslen(pszProj4)+1];
 strcpy(*prj4, pszProj4);
 CPLFree(pszProj4);
 }
 
 This code was working for years, but now it crashes on delete oSRS;.
 I've been searching for examples of how to use exportToProj4() in C++ but
 can only find Python examples.
 And I'm not a C++ developer, just a C# developer :)
 How should I now free oSRS?

The code looks OK and there's no fundamental reason why it would not work any 
longer. I highly suspect that you are running into a classical issue of a 
mismatch between the compile flags used in your application and the ones used 
by the GDAL built itself.

You could perhaps avoid that by letting GDAL do the allocation and 
deallocation with 

oSRS = (OGRSpatialReference*)OSRNewSpatialReference(NULL);

and

OGRSpatialReference::DestroySpatialReference(oSRS)

 
 Thanks for any advice.
 
 Paul
 
 *Paul Meems *
 Release manager, configuration manager
 and forum moderator of MapWindow GIS.
 www.mapwindow.org
 
 Owner of MapWindow.nl - Support for
 Dutch speaking users.
 www.mapwindow.nl

-- 
Geospatial professional services
http://even.rouault.free.fr/services.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] New option INDEX_COLUMNS for SQLite and GPKG

2014-01-25 Thread Rahkonen Jukka (Tike)

Hi Even,

Good points and vacuuming is also very important sometimes but but does not 
suit at all for a creation option. I will think about some text and examples 
that could be added into SQLite/Spatialite performance hints.

-Jukka-


Even Rouault wrote:

 Hi Jukka,

 I'm a bit ambivalent about providing a creation option for that (although that
 would not be an heresy). For a few reasons :
 - it is relatively easy to create an attribute index manually (once you know
 the syntax)
 - it is not necessarily to create it at layer creation time
 - it would potentially apply to all drivers that have a SQL engine behind

 But I agree that improving the documentation to advertize the interest of
 indexes and how to create them could be usefull. Perhaps you would want to
 propose a modified version of the HTML page ? (I think that the GPKG one could
 just point to the relevant section of the SQLite one, to avoid doc
 duplication)

 Even

 Hi,

 I guess that both SQLite/Spatialite and especially OGC Geopackage will be
 used by people who consider them more like file formats than as datebases.
 Such users may not know the power of indexes and they do not necessarily
 know anything about SQL and such.

 How about writing a few lines about the power and importance of indexes
 into the SQLite and GPKG driver pages? There could at least be on example
 about how to create a new index with ogrinfo, which must be a secret even
 for many advanced GDAL users. Better though, from user point of view,
 would be to implement a new layer creation option. I see a very similar
 case in SQLite/Spatialite
 COMPRESS_COLUMNS=column_name1[,column_name2, ...]: (Starting with GDAL
 1.10.0) A list of (String) columns that must be compressed
 The new -lco might be
 INDEX_COLUMNS=column_name1[,column_name2, ...]: (Starting with GDAL 2.0) A
 list of columns that will be indexed.

 I am not sure if -lco should somehow support also composite indexes.
 Perhaps users who know what those (and unique indexes) mean can also use
 SQL and create them with ogrinfo if they can see an example in the
 documentation. Thus -lco could be made to accept only one column per
 index. And index name in the db could be set automatically into something
 like
 layer_name_column_name_idx. The SQL that this -lco should fire is simply

 CREATE INDEX table_name_column_name_idx
 ON table_name (column_name);

 -Jukka Rahkonen-
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] exportToProj4

2014-01-25 Thread Paul Meems

Thanks Even,

This seems to be working. But unfortunately we have projection code in
several places, like
https://mapwingis.codeplex.com/SourceControl/latest#MapWinGIS/trunk/Processing/Projections.cppand
https://mapwingis.codeplex.com/SourceControl/latest#MapWinGIS/trunk/Grid/tkGridRaster.cpp(around
like 440).

I tried to use your suggestion in all those places, but it does compile but
doesn't run.
I'll need to let a true C++ developer look at it ;)

Thanks,



Paul

 *Paul Meems *
Release manager, configuration manager
and forum moderator of MapWindow GIS.
www.mapwindow.org

Owner of MapWindow.nl - Support for
Dutch speaking users.
www.mapwindow.nl




2014-01-26 Even Rouault even.roua...@mines-paris.org

 Le samedi 25 janvier 2014 23:50:10, Paul Meems a écrit :
  Hi all,
 
  Thanks to Tamas Szekeres we are now using his binaries from
  http://www.gisinternals.com/sdk/ with MapWinGIS, our mapping ActiveX.
  This has drastically simplified our build process and we are very
 grateful
  for Tamas' help.
 
  We're now struggling with some minor issues regarding our 'old' C++ code
  and the new binaries for GDAL, GEOS, Proj4, etc.
  Several of them I managed to solve, but I'm struggling with this one.
  We have code to read a prj file and get the Proj4 string:
 
  void ProjectionTools::GetProj4FromPRJFile(char * prjfileName, char **
  prj4)
  {
  FILE * pFile;
  pFile = fopen (prjfileName,r);
  if (pFile == NULL)
  {
  // Doesn't exist
  return;
  }
  fclose(pFile);
  pFile = NULL;
  OGRSpatialReference* oSRS = new OGRSpatialReference();
 
  char **papszPrj = CSLLoad(prjfileName);
  if (papszPrj == NULL)
  {
  return;
  }
 
  OGRErr eErr = oSRS-importFromESRI(papszPrj);
  if (eErr != OGRERR_NONE)
  {
  OGRErr eErr = oSRS-importFromProj4(*papszPrj);
  }
 
  CSLDestroy( papszPrj );
  char * pszProj4 = NULL;
  eErr = oSRS-exportToProj4( pszProj4 );
  delete oSRS; -- going wrong now
 
  *prj4 = new char[_tcslen(pszProj4)+1];
  strcpy(*prj4, pszProj4);
  CPLFree(pszProj4);
  }
 
  This code was working for years, but now it crashes on delete oSRS;.
  I've been searching for examples of how to use exportToProj4() in C++ but
  can only find Python examples.
  And I'm not a C++ developer, just a C# developer :)
  How should I now free oSRS?

 The code looks OK and there's no fundamental reason why it would not work
 any
 longer. I highly suspect that you are running into a classical issue of a
 mismatch between the compile flags used in your application and the ones
 used
 by the GDAL built itself.

 You could perhaps avoid that by letting GDAL do the allocation and
 deallocation with

 oSRS = (OGRSpatialReference*)OSRNewSpatialReference(NULL);

 and

 OGRSpatialReference::DestroySpatialReference(oSRS)

 
  Thanks for any advice.
 
  Paul
 
  *Paul Meems *
  Release manager, configuration manager
  and forum moderator of MapWindow GIS.
  www.mapwindow.org
 
  Owner of MapWindow.nl - Support for
  Dutch speaking users.
  www.mapwindow.nl

 --
 Geospatial professional services
 http://even.rouault.free.fr/services.html

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] gdaldem slope with -s 111120.0 works only at equator for lat/lon?

Re: [gdal-dev] Extra Decimal places added to ASCII gdal_translate mosaic

Re: [gdal-dev] Problem calling gdalwarp from within python script

[gdal-dev] New option INDEX_COLUMNS for SQLite and GPKG

Re: [gdal-dev] New option INDEX_COLUMNS for SQLite and GPKG

[gdal-dev] exportToProj4

Re: [gdal-dev] exportToProj4

Re: [gdal-dev] New option INDEX_COLUMNS for SQLite and GPKG

Re: [gdal-dev] exportToProj4

9 matches

Site Navigation

Mail list logo

Footer information