Re: [gdal-dev] gdal installation, geopdf not recognized

[Eli Adam]

Hi Jian,

On Mon, Jul 14, 2014 at 7:52 AM, Liu, Jian  wrote:
> Hello,
>
>
>
> I have been trying to install GDAL to convert USGS GeoPdf. Googling gave me
> a couple of links for quick installation for windows.
>

http://trac.osgeo.org/gdal/wiki/DownloadingGdalBinaries lists some
additional options.  I often use http://www.gisinternals.com/sdk/ from
Tamas.


>
>
> http://trac.osgeo.org/osgeo4w/wiki
>
> · http://www.lfd.uci.edu/~gohlke/pythonlibs/#gdal
> (GDAL‑1.11.0.win32‑py2.7.exe)
>
>
>
> I have 32 bit machine, windows 7 and python 2.7. There was a side-by-side
> configuration error, so I had to get that .dll, and I tried a couple of
> times. The installation seemed successful, however, I got error when reading
> a geopdf:
>
>
>
> ERROR 4: `C:\TestFolder\WI_Madison_West_20100723_TM_geo.pdf' not recognized
> as a supported file format.
>

I got this error from OSGeo4W too.  The last two lines of this page,
http://trac.osgeo.org/osgeo4w/ticket/408, lists the mailing list and
ticket tracker.  You can ask or report this error there.  Searching
through trac for OSGeo4W, I found this which seems like it might be
similar, http://trac.osgeo.org/osgeo4w/ticket/408

If you list a link to the file, it is easier for people to test.  I
found, this, ims.er.usgs.gov/gda_services/download?item_id=5954807 for
testing.  I tested with about a four month old download from
http://www.gisinternals.com/sdk/ and it worked showing this,

gdalinfo WI_Madison_West_20130722_TM_geo.pdf
Driver: PDF/Geospatial PDF
Files: WI_Madison_West_20130722_TM_geo.pdf
Size is 13656, 17407
Coordinate System is:
PROJCS["UTM Zone 16, Northern Hemisphere",
...
...
Corner Coordinates:
Upper Left  (  294830.111, 4779306.587) ( 89d31'22.05"W, 43d 8'19.31"N)
Lower Left  (  294317.106, 4761635.933) ( 89d31'21.23"W, 42d58'46.52"N)
Upper Right (  308692.951, 4778904.128) ( 89d21' 8.42"W, 43d 8'19.34"N)
Lower Right (  308179.946, 4761233.474) ( 89d21' 9.19"W, 42d58'46.51"N)
Center  (  301505.029, 4770270.031) ( 89d26'15.22"W, 43d 3'33.04"N)
Band 1 Block=1024x1024 Type=Byte, ColorInterp=Red
  Mask Flags: PER_DATASET ALPHA
Band 2 Block=1024x1024 Type=Byte, ColorInterp=Green
  Mask Flags: PER_DATASET ALPHA
Band 3 Block=1024x1024 Type=Byte, ColorInterp=Blue
  Mask Flags: PER_DATASET ALPHA
Band 4 Block=1024x1024 Type=Byte, ColorInterp=Alpha

So the file is fine but something appears to be wrong with the OSGeo4W
geopdf support. The binaries at http://www.gisinternals.com/sdk/ from
Tamas seem to properly support geopdf.


Best Regards, Eli

>
>
> Even though pdf is listed with gdalinfo –formats:  PDF (rw): Geospatial PDF
>
>
>
> Anybody could point me to a solution to this? It’s much appreciated.
>
> (I saw a previous post about cleaning before a new installation. That could
> be my problem too. But not sure how to do this with windows. Any clue would
> be helpful, thanks!)
>
>
>
> Regards,
>
> Jian
>
>
> ___
> 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

Re: [gdal-dev] gdal installation, geopdf not recognized

[Eli Adam]

On Mon, Jul 14, 2014 at 11:17 AM, Jürgen E.  wrote:
> Hi Eli,
>
> On Mon, 14. Jul 2014 at 10:40:08 -0700, Eli Adam wrote:
>> I got this error from OSGeo4W too.  The last two lines of this page,
>> http://trac.osgeo.org/osgeo4w/ticket/408, lists the mailing list and
>> ticket tracker.  You can ask or report this error there.  Searching
>> through trac for OSGeo4W, I found this which seems like it might be
>> similar, http://trac.osgeo.org/osgeo4w/ticket/408
>
> I can't reproduce that.  WI_Madison_West_20130722_TM_geo.pdf works fine
> with both the 32 and the 64bit build in OSGeo4W (using gdal-1.11.0-2).
>

I tried gdalinfo --debug on but that did not provide additional information.

gdalinfo --version  reports GDAL 1.11.0, released 2014/04/16

Before I try updating OSGeo4W and seeing if anything changes, is there
anything else to try to find the source of the error?  My install is
the result of an advanced install about three months ago and probably
updated about a month or two ago.

Thanks, Eli


>
> Jürgen
>
> --
> Jürgen E. Fischer norBIT GmbH   Tel. +49-4931-918175-31
> Dipl.-Inf. (FH)   Rheinstraße 13Fax. +49-4931-918175-50
> Software Engineer D-26506 Norden   http://www.norbit.de
>
> --
> norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
> Rheinstrasse 13, 26506 Norden
> GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502
>
> ___
> 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

Re: [gdal-dev] gdal installation, geopdf not recognized

[Eli Adam]

On Mon, Jul 14, 2014 at 12:35 PM, Jürgen E.  wrote:
> Hi Eli,
>
>> > On Mon, 14. Jul 2014 at 10:40:08 -0700, Eli Adam wrote:
>> >> Searching through trac for OSGeo4W, I found this which seems like it might
>> >> be similar, http://trac.osgeo.org/osgeo4w/ticket/408
>
>> > I can't reproduce that.  WI_Madison_West_20130722_TM_geo.pdf works fine
>> > with both the 32 and the 64bit build in OSGeo4W (using gdal-1.11.0-2).
>
>> Before I try updating OSGeo4W and seeing if anything changes, is there
>> anything else to try to find the source of the error?  My install is
>> the result of an advanced install about three months ago and probably
>> updated about a month or two ago.
>
> Ok, that's explains it.  #408 tries to explain that 1.11.0-2 is from
> 9 days ago and introduces pdf read support - earlier didn't have it.

More carefully reading, I now see that the fix was 9 days ago.  I
updated and as expected OSGeo4W reads geopdf fine.

Thanks, Eli

>
> Jürgen
>
> --
> Jürgen E. Fischer   norBIT GmbH Tel. +49-4931-918175-31
> Dipl.-Inf. (FH) Rheinstraße 13  Fax. +49-4931-918175-50
> Software Engineer   D-26506 Norden http://www.norbit.de
> QGIS release manager (PSC)  GermanyIRC: jef on FreeNode
>
> --
> norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
> Rheinstrasse 13, 26506 Norden
> GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502
>
> ___
> 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

[gdal-dev] GDAL 1.7.3 can't read tiff written by GDAL 1.11

[Eli Adam]

 Hi all,

I've got some recent tiff data that can't be read by GDAL 1.7.3
("gdalinfo.exe has stopped working").  It appears to work fine with
GDAL 1.11.  The output from GDAL 1.11 can't be read by GDAL 1.7.3
either.  Hmm, oddly it seems to work with GDAL 1.6.

I have an older MapServer and GDAL that I'd like to use with new data
without updating MapServer and GDAL so my goal is find a way to use or
alter the data so it is usable by GDAL 1.7.3.  I also want to know if
the data is valid and complies with the the geotif specification.

This is on Windows 7 and OSGeo4W although I also had some similar
issues on Ubuntu 10.04.  Below are GDAL 1.11 version, gdalinfo with
debug, listgeo, and finally gdal_translate output that can't be read
by GDAL 1.7.3 (attached).  There are messages about "GTIFF: converting
geokey to meters to fix bug in old libgeotiff" and "TIFFReadDirectory:
Warning, Unknown field with tag 2457 (0x999) encountered."  Further
below the GDAL1.11 information, is GDAL 1.7.3 showing that it can't be
read and the error output.

Do 06S08W19_gdal1_11_ouput2.tif and 06S08W19.tif conform to the geotif
specification and contain valid data? Any suggestions on how to keep
using my older install without updating?

Best regards, Eli

gdalinfo --version
GDAL 1.11.0, released 2014/04/16

gdalinfo 06S08W19.tif --debug on
GDAL: GDALOpen(06S08W19.tif, this=027C3F20) succeeds as GTiff.
Driver: GTiff/GeoTIFF
GDAL: GDALDefaultOverviews::OverviewScan()
Files: 06S08W19.tif
   06S08W19.tfw
Size is 3314, 5508
GTIFF: converting geokey to meters to fix bug in old libgeotiff
GTIFF: converting geokey to meters to fix bug in old libgeotiff
Coordinate System is:
PROJCS["NAD_1983_2011_StatePlane_Oregon_North_FIPS_3601_Ft_Intl",
GEOGCS["GCS_NAD_1983_2011",
DATUM["NAD_1983_2011",
SPHEROID["GRS_1980",6378137,298.257222101]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433]],
PROJECTION["Lambert_Conformal_Conic_2SP"],
PARAMETER["standard_parallel_1",44.34],
PARAMETER["standard_parallel_2",46],
PARAMETER["latitude_of_origin",43.66],
PARAMETER["central_meridian",-120.5],
PARAMETER["false_easting",8202099.737532808],
PARAMETER["false_northing",0],
UNIT["foot",0.3048,
AUTHORITY["EPSG","9002"]]]
Origin = (7367100.000,520508.000)
Pixel Size = (1.000,-1.000)
Metadata:
  AREA_OR_POINT=Area
  TIFFTAG_RESOLUTIONUNIT=2 (pixels/inch)
  TIFFTAG_XRESOLUTION=200
  TIFFTAG_YRESOLUTION=200
Image Structure Metadata:
  INTERLEAVE=PIXEL
OGRCT: PROJ >= 4.8.0 features enabled
OGRCT: Source: +proj=lcc +lat_1=44.34 +lat_2=46 +lat_0=43.66
 +lon_0=-120.5 +x_0=250 +y_0=0 +ellps=GRS80 +units=ft +no_defs
OGRCT: Target: +proj=longlat +ellps=GRS80 +no_defs
Corner Coordinates:
Upper Left  ( 7367100.000,  520508.000) (123d43'54.49"W, 45d 2'54.88"N)
Lower Left  ( 7367100.000,  515000.000) (123d43'51.43"W, 45d 2' 0.54"N)
Upper Right ( 7370414.000,  520508.000) (123d43' 8.37"W, 45d 2'56.19"N)
Lower Right ( 7370414.000,  515000.000) (123d43' 5.31"W, 45d 2' 1.84"N)
Center  ( 7368757.000,  517754.000) (123d43'29.90"W, 45d 2'28.36"N)
Band 1 Block=256x256 Type=Byte, ColorInterp=Red
Band 2 Block=256x256 Type=Byte, ColorInterp=Green
Band 3 Block=256x256 Type=Byte, ColorInterp=Blue
GDAL: GDALClose(06S08W19.tif, this=027C3F20)


listgeo 06S08W19.tif
TIFFReadDirectory: Warning, Unknown field with tag 2457 (0x999) encountered.
Geotiff_Information:
   Version: 1
   Key_Revision: 1.0
   Tagged_Information:
  ModelTiepointTag (2,3):
 000
 7367100  520508   0
  ModelPixelScaleTag (1,3):
 110
  End_Of_Tags.
   Keyed_Information:
  GTModelTypeGeoKey (Short,1): ModelTypeProjected
  GTRasterTypeGeoKey (Short,1): RasterPixelIsArea
  GTCitationGeoKey (Ascii,67): "PCS Name = NAD_1983_2011_StatePlane_Oregon_N
orth_FIPS_3601_Ft_Intl"
  GeographicTypeGeoKey (Short,1): User-Defined
  GeogCitationGeoKey (Ascii,92): "GCS Name = GCS_NAD_1983_2011
Datum = NAD_1
983_2011
Ellipsoid = GRS_1980
Primem = Greenwich
"
  GeogGeodeticDatumGeoKey (Short,1): User-Defined
  GeogAngularUnitsGeoKey (Short,1): Angular_Degree
  GeogEllipsoidGeoKey (Short,1): User-Defined
  GeogSemiMajorAxisGeoKey (Double,1): 6378137
  GeogInvFlatteningGeoKey (Double,1): 298.257222101
  GeogPrimeMeridianLongGeoKey (Double,1): 0
  Unknown-3059 (Short,1): Unknown-1
  ProjectedCSTypeGeoKey (Short,1): User-Defined
  ProjectionGeoKey (Short,1): User-Defined
  ProjCoordTransGeoKey (Short,1): CT_LambertConfConic_2SP
  ProjLinearUnitsGeoKey (Short,1): Linear_Foot
  ProjStdParallel1GeoKey (Double,1): 44.3
  ProjStdParallel2GeoKey (Double,1): 46
  ProjFalseOriginLongGeoKey (Double,1): -120.5
  ProjFalseOriginLatGeoKey (Double,1): 43.6

Re: [gdal-dev] GDAL 1.7.3 can't read tiff written by GDAL 1.11

[Eli Adam]

On Mon, Jul 21, 2014 at 1:46 PM, Even Rouault
 wrote:
> Le lundi 21 juillet 2014 22:18:27, Eli Adam a écrit :
>>  Hi all,
>>
>> I've got some recent tiff data that can't be read by GDAL 1.7.3
>> ("gdalinfo.exe has stopped working").  It appears to work fine with
>> GDAL 1.11.  The output from GDAL 1.11 can't be read by GDAL 1.7.3
>> either.  Hmm, oddly it seems to work with GDAL 1.6.
>>
>> I have an older MapServer and GDAL that I'd like to use with new data
>> without updating MapServer and GDAL so my goal is find a way to use or
>> alter the data so it is usable by GDAL 1.7.3.  I also want to know if
>> the data is valid and complies with the the geotif specification.
>
> Looks reasonable at first sight
>
>>
>> This is on Windows 7 and OSGeo4W although I also had some similar
>> issues on Ubuntu 10.04.  Below are GDAL 1.11 version, gdalinfo with
>> debug, listgeo, and finally gdal_translate output that can't be read
>> by GDAL 1.7.3 (attached).  There are messages about "GTIFF: converting
>> geokey to meters to fix bug in old libgeotiff"
>
> Yes, tricky issue with non-meter linear unit. See ticket
> https://trac.osgeo.org/gdal/ticket/3901 to get heavily confused.

I read that and am somewhat confused :) but have a basic understanding
of it as well now.  I tried gdal_translate -projwin 7367110 520505
7367120 520495 06S08W19.tif 06S08W19_gdal1_11_ouput3.tif --config
GTIFF_LINEAR_UNITS BROKEN to try and make a broken tiff to see if it
would work.  GDAL 1.7.3 can't read the output of that either.

>
> Related to that, I guess your listgeo is from libgeotiff 1.3 or older since it
> should display ProjFalseEastingGeoKey: 250.00 m normally

Using the OSGeo4W installer libgeotiff appears to be 1.3.0-3 (is there
a command line option to determine libgeotiff or libtiff version?).

I just looked these up on EPSG and now my basic understanding of
ticket 3901 is faltering.
http://www.epsg-registry.org/report.htm?type=selection&entity=urn:ogc:def:crs:EPSG::6558&entity=urn:ogc:def:crs:EPSG::6559&reportDetail=long&style=urn:uuid:report-style:default-with-urn&style_name=OGP%20Default%20With%20Urn&title=Oregon_foot_meter

Is it incorrect to report ProjFalseOriginEastingGeoKey (Double,1):
8202099.73753281 with ProjLinearUnitsGeoKey (Short,1): Linear_Foot?

>
>> and "TIFFReadDirectory:
>> Warning, Unknown field with tag 2457 (0x999) encountered."
>
> Cannot find its definition in the TIFF tag catalog, but shouldn't cause 
> issues.
> This will be ignored
>
>> Further
>> below the GDAL1.11 information, is GDAL 1.7.3 showing that it can't be
>> read and the error output.
>>
>> Do 06S08W19_gdal1_11_ouput2.tif and 06S08W19.tif conform to the geotif
>> specification and contain valid data? Any suggestions on how to keep
>> using my older install without updating?
>
> I managed to read your attachef file with latest state of 1.7 branch (1.7.3
> with a few additional fixes) on Linux, and cannot see anything in the log
> between this and 1.7.3 that could explain the issue. However, as more or less
> expected, the georeferencing is not read correctly (since #3901 was fixed in
> 1.8) and the false easting value is multiplied by 1. / 0.3048.

Would different versions of libgeotiff explain it working (with
incorrect georeferencing?) for you and erroring out for me?

>
> You will never (or with much difficulty) manage to make it work with non-meter
> linear units in old GDAL releases. I'd encourage you warping it into a UTM
> projection for example.

Thanks for the suggestion.  I'll pursue this and it sounds like this
will work for me.

Best regards, Eli

>
> Best regards,
>
> Even
>
> --
> 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] GDAL 1.7.3 can't read tiff written by GDAL 1.11

[Eli Adam]

>> I just looked these up on EPSG and now my basic understanding of
>> ticket 3901 is faltering.
>> http://www.epsg-registry.org/report.htm?type=selection&entity=urn:ogc:def:c
>> rs:EPSG::6558&entity=urn:ogc:def:crs:EPSG::6559&reportDetail=long&style=urn
>> :uuid:report-style:default-with-urn&style_name=OGP%20Default%20With%20Urn&t
>> itle=Oregon_foot_meter
>>
>> Is it incorrect to report ProjFalseOriginEastingGeoKey (Double,1):
>> 8202099.73753281 with ProjLinearUnitsGeoKey (Short,1): Linear_Foot?
>
> It is correct, but the listgeo output also lists afterwards something like :
>
> Projection Method: CT_LambertConfConic_2SP
>ProjFalseOriginLatGeoKey: 43.67 ( 43d40' 0.00"N)
>ProjFalseOriginLongGeoKey: -120.50 (120d30' 0.00"W)
>ProjStdParallel1GeoKey: 44.33 ( 44d20' 0.00"N)
>ProjStdParallel2GeoKey: 46.00 ( 46d 0' 0.00"N)
>ProjFalseEastingGeoKey: 250.00 m
>ProjFalseNorthingGeoKey: 0.00 m
> Projection Linear Units: 9002/foot (0.304800m)
>
> where ProjFalseEastingGeoKey is normalized in meters.

I missed this on initial reading.  Thanks for pointing it out and
letting me learn some more.

>
>>

>> > I managed to read your attachef file with latest state of 1.7 branch
>> > (1.7.3 with a few additional fixes) on Linux, and cannot see anything in
>> > the log between this and 1.7.3 that could explain the issue. However, as
>> > more or less expected, the georeferencing is not read correctly (since
>> > #3901 was fixed in 1.8) and the false easting value is multiplied by 1.
>> > / 0.3048.
>>
>> Would different versions of libgeotiff explain it working (with
>> incorrect georeferencing?) for you and erroring out for me?
>
> No idea why it crashes on osgeo4w. Well, I somehow remember that there have
> been ABI changes in libgeotiff between versions, but if that was the case of a
> mismatch between actual libgeotiff ABI and the one expected by the GDAL build,
> then it would likely crash on most geotiff files, and not that one only. Does 
> it
> crash only on that geotiff ? Anyway that's an old version, and you cannot undo
> the past, just try to make the future better ;-)

GDAL 1.7.3 in OSGeo4W only crashes on this collection of geotiffs and
works fine on other files.  Thanks for spending time on what is
probably perceived by you as an ancient version and probably of little
interest to you.  You are always making the future better; thanks for
all your work in that regard.  Thanks also for going out of your way
to help all users at all levels.  I've found the GDAL-dev list to be
kind and welcoming to all who write.

Sincerely, Eli

>
> Even
>
> --
> 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] GeoPDF translation

[Eli Adam]

Hi rkologist,

The driver page [0] and a wiki page [1] indicate that you can crop to the
NEATLINE.

Jim, if you are still following this thread, you can edit the wiki page
with what you found works well for what you were doing too.

GDAL has really made the USGS new generation topos more accessible.

[0] http://www.gdal.org/frmt_pdf.html
[1] http://trac.osgeo.org/gdal/wiki/USGS_PDF_Topo

Best regards, Eli



On Wed, Jul 23, 2014 at 6:26 PM, rkologist  wrote:

> Can someone help me figure out where to insert the code to also have this
> crop to the neat line?  I need to tile several maps together, and it would
> really help.
>
> Thanks
>
>
>
> --
> View this message in context:
> http://osgeo-org.1560.x6.nabble.com/gdal-dev-GeoPDF-translation-tp3742508p5152932.html
> Sent from the GDAL - Dev mailing list archive at Nabble.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

Re: [gdal-dev] Adding Vertex To Linestring in Existing shapefile(Python)

[Eli Adam]

Hi Justin,

ogr2ogr -segmentize max_dist:(starting with GDAL 1.6.0) maximum
distance between 2 nodes. Used to create intermediate points . Mmight
do what you want.

Best regards, Eli

On Wed, Jul 23, 2014 at 2:08 PM, Justin Williams  wrote:
>
> Hello All. I'm trying to add a vertex to a linestring inside of a shapefile 
> and save the changes that I've made. So if I have a line that has 2 vertices. 
> When I open the shapefile up again(in Global Mapper, QGIS,etc.) I have 3 
> vertices. How is this accomplished in gdal/ogr?
>
> ___
> 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

Re: [gdal-dev] Adding a "Commercial support" section on gdal.org?

[Eli Adam]

Adding a support section like some other OSGeo projects is a good idea (in
my opinion).  This is a way for people to use the project webpage to find
those who are most substantially contributing to the project and know the
most about GDAL/OGR.


On Thu, Aug 21, 2014 at 5:46 AM,  wrote:

> Charta is interested to be listed as experienced provider if gdal.org
> will ever add info about commercial support.
>
> Nevertheless, I think this item has to receive more attention, considering
> at least:
> * the license of GDAL. Using MIT license means being expecially open to
> commercial usage. I don't know if this is really consequential with
> selecting a group of commercial providers instead of being agnostic about
> usage of the code and technology created (I don't agree with this, but...);
> * usually support means choice between several tools and technologies,
> being a core contributor could mean some bias about recurring to a specific
> tool. Being listed as such could become a double-edged sword;
>

If you are looking for GDAL/OGR support (on the gdal.org web page) you have
already made your technology choice.  If you are looking for support in
selecting a technology you should not be looking on gdal.org but rather
collecting references or otherwise doing research on appropriate support in
whatever domain you're in.  gdal.org is not the the proper place to look
for support on javascript libraries or other non-GDAL/OGR topics.  Someone
may be better off with advice to use something other than GDAL/OGR but
gdal.org is not the place to get that advice (the people and companies
listed there may give that advice if approached but they would best know
what is out of the GDAL/OGR scope).


> * any evaluation aobut support should be based on the help provided to the
> user and not about the contribution to the project. The client shoud be
> able to choose if he needs "broad" or "focused" support, if he needs new
> developments or better integration and so on. Listing experiences or
> specialisation (geodatabases, remote sensing and so on) could be more
> useful.
>

A prudent customer might evaluate support by referrals and reviews based on
help provided to the user but gdal.org is in no place to evaluate that.
gdal.org is certainly in a place to evaluate and recommend those who have a
history of competently contributing to the project (tickets, patches,
commits, emails correctly answered, relevant presentations at FOSS4G, etc).

The OSGeo Service providers directory,
http://www.osgeo.org/search_profile?SET=1&MUL_TECH[0]=00013 already
provides a mechanism for self listing anything the person listing wants.
This remains a valuable resource for researching support options but gives
no indication of who is competently contributing to the project.

The PostGIS support page lists focus area of support,
http://postgis.net/support

Best regards, Eli


>
> Even's case is noteworthy, because he is more than a "Core contributor",
> but a project leader for GDAL. When his affiliation to École des Mines
> changed to his own company, Spatialys, I thought this was a very good move
> because he could more easily provide consulting services to commercial
> entities. Maybe his visibility as a prominent person in this community is
> already warranted, I understand that his proposal is addressed to others,
> but I think gdal-dev is about developing, although the list provides a lot
> of help to users, is this the right place?
>
c
>
> On Thu, Aug 20, 2014 at 10:02:35 PM, Even Rouault wrote:
>
> Date: Wed, 20 Aug 2014 22:02:35 +0200
> From: Even Rouault 
> To: "gdal-dev@lists.osgeo.org" 
> Subject: [gdal-dev] Adding a "Commercial support" section on gdal.org
> ?
> Message-ID: <201408202202.36022.even.roua...@spatialys.com>
> Content-Type: Text/Plain;  charset="us-ascii"
>
>
> Hi,
>
> I'm wondering if there would be a concensus and interest to add a
> "Commercial
> support" section on gdal.org. A number of OSGeo projects have such
> page (see
> [1]), so that wouldn't be completely awkward to have one for GDAL as
> well.
>
> The OSGeo Service provider database reference 137
> companies/individuals that
> have registered themselves as providing GDAL support ([2]) ! Pretty
> cool, but
> I'm wondering how a user not familiar with the project could
> effectively use
> that list to identify core contributors from casual advanced users.
>
> If we agree for adding a "Commercial support" section, the question is
> : on
> which criteria do we accept an organization/individual to be listed in
> the
> section ? We would want them to be as most objective and non debatable
> as
> possible.
> A simple criterion could be anyone who has commit rights (in trunk,
> not just
> in a sandbox or customer branch). There are currently 56 SVN
> committers. That
> could be strengthened with a minimum number of commits/lines changed
> during a
> period, but we perhap

Re: [gdal-dev] GDAl no more compiling on Ubunut 12.0.4

[Eli Adam]

> It compiled GDAL on Ubuntu 12.0.4 LTS about 6 months ago.
> Today I updated the git sources,
> a new error at the very beginning of compilation stops everything
>
> "Configure" seems to have changed a lot.
> Any suggestions?

I can compile svn trunk on 12.04 as of today.  I started with a make
clean and then this is my configure:

./configure --with-poppler --with-spatialite=yes --with-java=yes
--with-mdb=yes --with-python --with-curl --with-expat --with-libkml

make clean might help.  There are a lot of different libraries which
can be internal or external and many combinations to test so not sure
how similar my setup is to yours.

Best regards, Eli


> Cheers,
> Rémi-C
>
> //error//
> In file included from cpl_conv.h:35:0,
>  from cpl_conv.cpp:33:
> cpl_port.h:89:2: error: #error "Unexpected value for SIZEOF_INT"
> cpl_port.h:93:2: error: #error "Unexpected value for SIZEOF_UNSIGNED_LONG"
> cpl_port.h:97:2: error: #error "Unexpected value for SIZEOF_VOIDP"
> 
>
> ___
> 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

Re: [gdal-dev] Associate single point coordinates to image.

[Eli Adam]

GDAL reads EXIF data and you can grab that output and then send it
into an OGR output.  I used to have a bash script that did that, but
then I found there were some tricky things to overcome and found that
GpsPrune is really good at this.

GpsPrune can also correlate a GPS track and time stamped photos
lacking EXIF location data.  It exports KML points for the photos.

ExifTool has lots of EXIF data manipulation capacity,
http://www.sno.phy.queensu.ca/~phil/exiftool/


Best regards, Eli

On Fri, Nov 14, 2014 at 3:38 AM, deve  wrote:
> Yes. The final effect is the same: photo--> location-->image over the map.
>
>
>
> --
> View this message in context: 
> http://osgeo-org.1560.x6.nabble.com/Associate-single-point-coordinates-to-image-tp5172985p5173000.html
> Sent from the GDAL - Dev mailing list archive at Nabble.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

Re: [gdal-dev] Associate single point coordinates to image.

[Eli Adam]

I think that this is generally call "geotagging" which might help
while looking for options.

Eli

On Fri, Nov 14, 2014 at 9:03 AM, Eli Adam  wrote:
> GDAL reads EXIF data and you can grab that output and then send it
> into an OGR output.  I used to have a bash script that did that, but
> then I found there were some tricky things to overcome and found that
> GpsPrune is really good at this.
>
> GpsPrune can also correlate a GPS track and time stamped photos
> lacking EXIF location data.  It exports KML points for the photos.
>
> ExifTool has lots of EXIF data manipulation capacity,
> http://www.sno.phy.queensu.ca/~phil/exiftool/
>
>
> Best regards, Eli
>
> On Fri, Nov 14, 2014 at 3:38 AM, deve  wrote:
>> Yes. The final effect is the same: photo--> location-->image over the map.
>>
>>
>>
>> --
>> View this message in context: 
>> http://osgeo-org.1560.x6.nabble.com/Associate-single-point-coordinates-to-image-tp5172985p5173000.html
>> Sent from the GDAL - Dev mailing list archive at Nabble.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

Re: [gdal-dev] Can we combine all layers of kml into single GeoJSON

[Eli Adam]

>
> Just thinking, but wouldn't it be nice to have "ogrbuildvrt" tool that would
> take list of OGR supported layers and outputs a simple vrt with one  union
> layer like the one in your example?
>

There is this script,
https://svn.osgeo.org/gdal/trunk/gdal/swig/python/samples/ogr2vrt.py,
with details here,
http://lists.osgeo.org/pipermail/gdal-dev/2009-October/022522.html.
It might get you part of the way.

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

Re: [gdal-dev] gdalwarp on a .vrt: Using internal nodata values (eg 0) for image (?)

[Eli Adam]

On Thu, Jun 11, 2015 at 2:38 PM, Ari Simmons  wrote:
> One notably huge difference is that there is a huge jump in pixel size (from
> 0.0008323 to 205.686440189378940)...
>
> ah, duh. Unit change.
>
> On Thu, Jun 11, 2015 at 2:26 PM, Ari Simmons  wrote:
>>
>> I am experimenting with using 'gdalwarp' on a .vrt (first time), but I'm
>> not sure what I'm doing wrong. I've been running this:
>>
>> >> gdalwarp -s_srs EPSG:4326 -t_srs EPSG:3857 -r bilinear -of VRT
>> >> merged.vrt srtm_merged_3857.vrt
>>
>> and it processes fast (far far *too fast* for this global file) and
>> returns

That is the right speed (~0 seconds) and disk space (~0MB).  That is
because it doesn't actually do anything except write down notes of
what it would have done (and will do in the future if you ask for it).
I like testing large VRT files by outputting a subwindow tif like
this:

gdal_translate -13813007 5569641 -13809113 5572598
srtm_merged_3857.vrt my_subwindow.tif --config  GDAL_CACHEMAX 800

If things look good on the subwindow, then it is time for all the I/O
waiting, processor cycles, and storage space.  Evaluating a few
places, especially where tiles come together can find things early
without all the wait.

HTH, Eli

>>
>> >> Creating output file that is 194835P X 479814L.
>> >> Processing input file merged.vrt
>> >> Using internal nodata values (eg. 0) for image merged.vrt
>>
>> The return .vrt file definitely doesn't appear right...a quick look at the
>> returned file:
>>
>> input:
>>
>> Size is 432000, 208800
>> Coordinate System is:
>> GEOGCS["WGS 84",
>> DATUM["WGS_1984",
>> SPHEROID["WGS 84",6378137,298.257223563,
>> AUTHORITY["EPSG","7030"]],
>> AUTHORITY["EPSG","6326"]],
>> PRIMEM["Greenwich",0],
>> UNIT["degree",0.0174532925199433],
>> AUTHORITY["EPSG","4326"]]
>> Origin = (-180.0004170,84.0004166)
>> Pixel Size = (0.0008323,-0.0008323)
>> Corner Coordinates:
>> Upper Left  (-180.0004167,  84.0004167) (180d 0' 1.50"W, 84d 0' 1.50"N)
>> Lower Left  (-180.0004167, -89.9995833) (180d 0' 1.50"W, 89d59'58.50"S)
>> Upper Right ( 179.9995833,  84.0004167) (179d59'58.50"E, 84d 0' 1.50"N)
>> Lower Right ( 179.9995833, -89.9995833) (179d59'58.50"E, 89d59'58.50"S)
>> Center  (  -0.0004167,  -2.9995833) (  0d 0' 1.50"W,  2d59'58.50"S)
>> Band 1 Block=128x128 Type=Int16, ColorInterp=Gray
>>   NoData Value=0
>>   Overviews: 216000x104400, 108000x52200, 54000x26100, 27000x13050,
>> 13500x6525,
>> 6750x3263, 3375x1632, 1688x816, 844x408, 422x204
>>
>> and output file:
>>
>>  Size is 193861, 479814
>> Coordinate System is:
>> PROJCS["WGS 84 / Pseudo-Mercator",
>> GEOGCS["WGS 84",
>> DATUM["WGS_1984",
>> SPHEROID["WGS 84",6378137,298.257223563,
>> AUTHORITY["EPSG","7030"]],
>> AUTHORITY["EPSG","6326"]],
>> PRIMEM["Greenwich",0,
>> AUTHORITY["EPSG","8901"]],
>> UNIT["degree",0.0174532925199433,
>> AUTHORITY["EPSG","9122"]],
>> AUTHORITY["EPSG","4326"]],
>> PROJECTION["Mercator_1SP"],
>> PARAMETER["central_meridian",0],
>> PARAMETER["scale_factor",1],
>> PARAMETER["false_easting",0],
>> PARAMETER["false_northing",0],
>> UNIT["metre",1,
>> AUTHORITY["EPSG","9001"]],
>> AXIS["X",EAST],
>> AXIS["Y",NORTH],
>> EXTENSION["PROJ4","+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0
>> +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext  +no_defs"],
>> AUTHORITY["EPSG","3857"]]
>> Origin = (-19837179.64248511900,18807657.84885524600)
>> Pixel Size = (205.686440189378940,-205.686440189378940)
>> Corner Coordinates:
>> Upper Left  (-19837179.642,18807657.849) (178d12' 1.50"W, 84d 0' 1.50"N)
>> Lower Left  (-19837179.642,-79883575.764) (178d12' 1.50"W, 89d59'58.50"S)
>> Upper Right (20037399.339,18807657.849) (179d59'56.47"E, 84d 0' 1.50"N)
>> Lower Right (20037399.339,-79883575.764) (179d59'56.47"E, 89d59'58.50"S)
>> Center  (  100109.848,-30537958.958) (  0d53'57.49"E, 89d 2'43.78"S)
>> Band 1 Block=512x128 Type=Int16, ColorInterp=Gray
>> Overviews: 96931x239907, 48466x119954, 24233x59977, 12117x29989, 6059x14995,
>> 3030x7498, 1515x3749, 758x1875, 379x938, 191x471
>>
>> One notably huge difference is that there is a huge jump in pixel size
>> (from 0.0008323 to 205.686440189378940)...
>
>
>
> ___
> 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

Re: [gdal-dev] gdalwarp on a .vrt: Using internal nodata values (eg 0) for image (?)

[Eli Adam]

On Fri, Jun 12, 2015 at 11:25 AM, Ari Simmons  wrote:
> Do you mean
>
> gdal_translate -te -13813007 5569641 -13809113 5572598
> srtm_merged_3857.vrt my_subwindow.tif --config  GDAL_CACHEMAX 800
>
> ?

Oops, I made a bad typo by omitting -projwin:

gdal_translate -projwin -13813007 5569641 -13809113 5572598
srtm_merged_3857.vrt my_subwindow.tif --config  GDAL_CACHEMAX 800

Best regards, Eli

>
> On Thu, Jun 11, 2015 at 3:08 PM, Eli Adam  wrote:
>>
>> On Thu, Jun 11, 2015 at 2:38 PM, Ari Simmons 
>> wrote:
>> > One notably huge difference is that there is a huge jump in pixel size
>> > (from
>> > 0.0008323 to 205.686440189378940)...
>> >
>> > ah, duh. Unit change.
>> >
>> > On Thu, Jun 11, 2015 at 2:26 PM, Ari Simmons 
>> > wrote:
>> >>
>> >> I am experimenting with using 'gdalwarp' on a .vrt (first time), but
>> >> I'm
>> >> not sure what I'm doing wrong. I've been running this:
>> >>
>> >> >> gdalwarp -s_srs EPSG:4326 -t_srs EPSG:3857 -r bilinear -of VRT
>> >> >> merged.vrt srtm_merged_3857.vrt
>> >>
>> >> and it processes fast (far far *too fast* for this global file) and
>> >> returns
>>
>> That is the right speed (~0 seconds) and disk space (~0MB).  That is
>> because it doesn't actually do anything except write down notes of
>> what it would have done (and will do in the future if you ask for it).
>> I like testing large VRT files by outputting a subwindow tif like
>> this:
>>
>> gdal_translate -13813007 5569641 -13809113 5572598
>> srtm_merged_3857.vrt my_subwindow.tif --config  GDAL_CACHEMAX 800
>>
>> If things look good on the subwindow, then it is time for all the I/O
>> waiting, processor cycles, and storage space.  Evaluating a few
>> places, especially where tiles come together can find things early
>> without all the wait.
>>
>> HTH, Eli
>>
>> >>
>> >> >> Creating output file that is 194835P X 479814L.
>> >> >> Processing input file merged.vrt
>> >> >> Using internal nodata values (eg. 0) for image merged.vrt
>> >>
>> >> The return .vrt file definitely doesn't appear right...a quick look at
>> >> the
>> >> returned file:
>> >>
>> >> input:
>> >>
>> >> Size is 432000, 208800
>> >> Coordinate System is:
>> >> GEOGCS["WGS 84",
>> >> DATUM["WGS_1984",
>> >> SPHEROID["WGS 84",6378137,298.257223563,
>> >> AUTHORITY["EPSG","7030"]],
>> >> AUTHORITY["EPSG","6326"]],
>> >> PRIMEM["Greenwich",0],
>> >> UNIT["degree",0.0174532925199433],
>> >> AUTHORITY["EPSG","4326"]]
>> >> Origin = (-180.0004170,84.0004166)
>> >> Pixel Size = (0.0008323,-0.0008323)
>> >> Corner Coordinates:
>> >> Upper Left  (-180.0004167,  84.0004167) (180d 0' 1.50"W, 84d 0' 1.50"N)
>> >> Lower Left  (-180.0004167, -89.9995833) (180d 0' 1.50"W, 89d59'58.50"S)
>> >> Upper Right ( 179.9995833,  84.0004167) (179d59'58.50"E, 84d 0' 1.50"N)
>> >> Lower Right ( 179.9995833, -89.9995833) (179d59'58.50"E, 89d59'58.50"S)
>> >> Center  (  -0.0004167,  -2.9995833) (  0d 0' 1.50"W,  2d59'58.50"S)
>> >> Band 1 Block=128x128 Type=Int16, ColorInterp=Gray
>> >>   NoData Value=0
>> >>   Overviews: 216000x104400, 108000x52200, 54000x26100, 27000x13050,
>> >> 13500x6525,
>> >> 6750x3263, 3375x1632, 1688x816, 844x408, 422x204
>> >>
>> >> and output file:
>> >>
>> >>  Size is 193861, 479814
>> >> Coordinate System is:
>> >> PROJCS["WGS 84 / Pseudo-Mercator",
>> >> GEOGCS["WGS 84",
>> >> DATUM["WGS_1984",
>> >> SPHEROID["WGS 84",6378137,298.257223563,
>> >> AUTHORITY["EPSG","7030"]],
>> >> AUTHORITY["EPSG","6326"]],
>> >> PRIMEM["Greenwich",0,
>> >> AUTHORITY["EPSG","8901"]],
>> >> UNIT["degree",0.0174532925199433,
>> >> AUTHORITY["EPSG","9122"]],
>>

Re: [gdal-dev] Doc: driver + config options summary pages [was Re: How to know which formats allow editing with ogrinfo?]

[Eli Adam]

On Sun, Nov 17, 2019 at 5:42 PM Eli Adam  wrote:
> > https://gdal.org/drivers/raster/index.html
> > https://gdal.org/drivers/vector/index.html

These two tables have been updated.  Please check them over.  Let me
know if anything needs to be changed/updated.

Best regards, Eli
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Reconsidering release cycle length ?

[Eli Adam]

On Mon, Apr 27, 2020 at 10:20 AM Even Rouault
 wrote:
>
>
> One year between feature versions is quite a lot. Perhaps 6 months would be a 
> good compromise between having enough time to mature a complex feature and 
> faster delivery of it to people not directly consuming master. A consequence 
> of this is that our usual policy of supporting the last released branch 
> during the development cycle of the next release would also go to 6 month (to 
> avoid supporting too many branches at the same time), or perhaps even 4 (see 
> below example)
>
> I've also heard voices wishing to have more frequent bugfix releases. Every 2 
> months could be reasonable.
>
> Of course depending on what comes to master, things could be reconsidered to 
> let a bit more time for maturing a feature if needed, so 6 months is more an 
> indication than a firm delay. This is also dependent on people doing the 
> actual work. I'll do my share, but help always welcome.
>

Perhaps another perspective on this is that since GDAL has a longer
release cycle, supports releases for a long time, is a fairly
innovative library with new drivers, new features, and improvements;
it compels people to track master and engage the project.  This
provides reliable testing for the project on various compilers,
hardware architecture, novel driver combinations, conflicts with other
software, and many other things that won't ever be fully covered in CI
type things.  If people were not compelled to track master, then this
engagement with the project might be reduced or pushed to releases
with a less interactive feedback (i.e. they won't be testing patches
or recent commits).  From my own personal experience, GDAL has been
the only project worth tracking master and engaging in this way.
Other projects, I wait for the release and take a binary and am less
in a position to provide testing or meaningful feedback.  Tracking
master and engaging with GDAL has been a rewarding experience for me
over the years.

Just another way to look at this.  I'm not sure if release cycle would
impact the number of people tracking master or the level of engagement
there but it might be worth considering.

I notice mostly Even's work on releases.  People wanting bug releases
more frequently could start by helping on releases.

Best regards, Eli


>
>
> Thoughts ?
>
>
>
> Even
>
>
>
> --
>
> Spatialys - Geospatial professional services
>
> http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] gdal_viewshed

[Eli Adam]

Congrats on another great release!

On Thu, May 7, 2020 at 7:20 AM Even Rouault  wrote:
>
>
> The 3.1.0 release is a new feature release with the following highlights:
>
> - [gdal_viewshed](https://gdal.org/programs/gdal_viewshed.html):
>
> new utility for viewshed algorithm
>

On the documentation of this, it says:
[with the image with two dots] A computed visibility for two separate
-ox and -oy points on a DEM.
gdal_viewshed -md 500 -ox -10147017 -oy 5108065 source.tif destination.tif

The image with two dots makes me think that there can be multiple
observer inputs.  Is that the case?  Is the syntax for that just to
keep adding more -ox, -oy, (and oz)?  For instance, gdal_viewshed -md
500 -ox -10147017 -oy 5108065 -ox -10147117 -oy 5108165+100 source.tif
destination.tif

Best regards, Eli
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] gdal_viewshed

[Eli Adam]

Hi Pedro,

On Thu, May 7, 2020 at 4:03 PM Pedro Venâncio  wrote:
>
> Hi,
>
> I'm trying the new gdal_viewshed and it is in fact really quick! But the 
> result is completely different than other viewshed analysis algorithms:
>
> https://cld.pt/dl/download/e80216bb-d7eb-40b0-b6da-8e45572e9eb3/viewshed.jpg
>
> https://cld.pt/dl/download/ee993a0b-cf86-462a-b831-307aecde7865/viewshed2.jpg
>
> GRASS and Visibility Analysis plugin for QGIS have almost the same result. 
> The result from gdal_viewshed seems completely overrated. The options I'm 
> using are [almost] the same in both algorithms.
>
> gdal_viewshed -b 1 -md 28000.0 -ox -41597.922 -oy 71254.049 -oz 21.6 -tz 10.0 
> -vv 1 -cc 0.85714 -f GTiff path_to_mdt.tif path_to_output.tif
>

Does -tz 10.0 in effect raise your DEM target elevation by 10 units?
Was the same done in GRASS and the Visibility Analysis plugin for
QGIS?

Was the observer height of -oz 21.6 the same for all three as well?

Best regards, Eli

> Has anyone else this experience?
>
> Thanks! Best regards,
> Pedro Venâncio
>
>
> Howard Butler  escreveu no dia quinta, 7/05/2020 à(s) 17:41:
>>
>>
>>
>> > On May 7, 2020, at 11:05 AM, Eli Adam  wrote:
>> >
>> > The image with two dots makes me think that there can be multiple
>> > observer inputs.  Is that the case?  Is the syntax for that just to
>> > keep adding more -ox, -oy, (and oz)?  For instance, gdal_viewshed -md
>> > 500 -ox -10147017 -oy 5108065 -ox -10147117 -oy 5108165+100 source.tif
>> > destination.tif
>>
>> The picture is a poor example. You can't do multiple obvservers, but you can 
>> run a bunch of masks together and then merge to get a multipoint viewshed. I 
>> indeed made two masks with gdal_viewshed and then merged them together to 
>> make that picture.
>>
>> That picture or the docs should maybe be updated to reflect a more common 
>> scenario with better description. File a ticket and attach some language and 
>> pictures to it as you start playing with it and we can merge it.
>>
>> Thanks,
>>
>> Howard
>> ___
>> gdal-dev mailing list
>> gdal-dev@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev



-- 
Eli L Adam, PLS
Lincoln County Surveyor's Office
880 NE 7th Street
Newport, OR 97365
541-574-1289
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Appending to a single feature class in a gdb via ogr2ogr

[Eli Adam]

Hi Maggie,

On Mon, Apr 27, 2020 at 9:03 AM Maggie Wooten  wrote:
>
> First, I apologize if I am using this mailing list improperly. This is my 
> first time here.

Asking questions is an appropriate use of the list.

>
> I am trying to iterate over some shapefiles (109 shapefiles to be exact) and 
> append them to a *single* feature class in an output geodatabase, but the 
> resulting output geodatabase is one with 100 feature classes that looks like 
> this:
>

Do all the shapefiles have (exactly) the same fields?  If not, it
probably won't work.

> INFO: Open of `output.gdb' using driver `FileGDB' successful.
> 1: output (Multi Polygon)
> 2: output_1 (Multi Polygon)
> 3: output_1_2 (Multi Polygon)
> 4: output_1_2_3 (Multi Polygon)
> 5: output_1_2_3_4 (Multi Polygon)
> .
> 99: 
> output_1_2_3_4_5_6_7_8_9_10_11_12_13_14_15_16_17_18_19_20_21_22_23_24_25_26_27_28_29_30_31_32_33_34_35_36_37_38_39_40_41_42_43_44_45_98
>  (Multi Polygon)
> 100: 
> output_1_2_3_4_5_6_7_8_9_10_11_12_13_14_15_16_17_18_19_20_21_22_23_24_25_26_27_28_29_30_31_32_33_34_35_36_37_38_39_40_41_42_43_44_45_99
>  (Multi Polygon)
>
>
> These are the commands I'm running in the iteration:
>
> if i == 0: "ogr2ogr -nln output -a_srs EPSG:4326 -t_srs EPSG:4326 -f 
> "FileGDB" output.gdb input1.shp"
>
> else: "ogr2ogr -nln output -a_srs EPSG:4326 -t_srs EPSG:4326 -update -append 
> -f "FileGDB" output.gdb inputX.shp"
>
>
> What am I doing wrong here? How can I get the desired result? I tried a bunch 
> of different things and flags and still could not get it all to append to one 
> feature class. Any advice would be greatly appreciated and I'd be happy to 
> provide whatever information may be necessary.
>
I'm not quite sure what is going wrong there.  I didn't try with an
output of FileGDB but did something similar all with shapefiles.  The
final resulting combined shapefile could probably be manually
ogr2ogr'ed into a FileGDB.

I did this on Ubuntu using Bash.  If you're using a different shell,
you will need different command syntax.  Specifically variables,
filenames without extensions, quoting, escape characters and other
things all need adjustment.  Complicated filenames with spaces or
other symbols can make this more difficult too.

mkdir merged

This is to make an "empty" shapefile with the correct fields and types
and an additional field named s_file to put the source file name in
later:
ogr2ogr -sql "select *, '' as s_file from
Surveys_Invalid_ManualFix_7of7 where SURVEYID='fake'"
merged/surveys_v1.shp Surveys_Invalid_ManualFix_7of7.shp -nln
surveys_v1

This is to check that my empty shapefile turned out okay:
ogrinfo merged/surveys_v1.shp -al

(I worked in a directory where I was selecting ALL the shapefiles, all
of which have the same fields):
FILES=*.shp

for f in $FILES; do g=${f%%.*}; ogr2ogr -sql "select *, '$g' as s_file
from $g" -update -append merged/surveys_v1.shp $f -nln surveys_v1;
done

This is to check that my shapefile is no longer empty and turned out okay:
ogrinfo merged/surveys_v1.shp -al

If you are using DOS on windows, here is a note (untested) from some
previous work.  I don't have windows readily available to test it (the
% might need to be %%):

for %f in (*.shp) do ogr2ogr -sql "select *, '%~nf' as s_file from
%~nf" -update -append merged\output.shp %f -nln output


Hope that helps.

Best regards, Eli

> Thank you!
> Ma
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] [SeasonOfDocs] Offers for GDAL documenting

[Eli Adam]

On Mon, Jun 17, 2019 at 5:43 AM Even Rouault  wrote:
>
> Hi,
>
> this is really great news ! Given my experience with the project, I'm rather
> far from being representative of someone less familiar with it or with a non-
> developer profile, so thoughts from the broader GDAL community on what they
> feel is the most missing would be welcome.
>

There are some things that are very basic that might make the
documentation more understandable to a beginner.  I'm not sure if
these things are true or I've made them up or they are supposed to be
too obvious to state.

-nln = New Layer Name
-nlt = New Layer Type
-a_srs = assign spatial reference system
-t_srs = target spatial reference system
-s_srs = source spatial reference system

-ot = output type
-of = output format

Are those true?  If not, I've used them to better understand (and
remember) the options.

Best regards, Eli


> One thing I've in mind - this is rather a detail - is that we lost a bit of
> content (build requirements for each driver) during the Sphinx migration, as
> pointed out by
> https://github.com/OSGeo/gdal/issues/1204#issuecomment-498624481 , so this
> could be a potential task.
>
> More generally, I feel we might need more tutorial-like / how-to style
> documentation. The current documentation is hopefully rather decent as a
> reference guide, but lacking on the quick-start side. On the wiki, there are
> some source of information, mostly from
> https://trac.osgeo.org/gdal/wiki/UserDocs , that could be interesting to
> migrate partly on the main documentation, but with a critical eye (some of the
> hints might be outdated due to later improvements, etc)
>
> Lynden, perhaps you've also suggestions from your practice of the project and
> its documentation on what you'd like to see added ?
>
> Even
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Generating Viewsheds without Using Sightlines

[Eli Adam]

On Mon, Sep 30, 2019 at 11:54 AM Even Rouault
 wrote:
>
> On lundi 30 septembre 2019 20:10:38 CEST Tamas Szekeres wrote:
> > Hi,
> >
> > I've implemented a viewshed algorithm a while ago, by utilizing a modified
> > version of the algorithm published at
> > https://www.asprs.org/wp-content/uploads/pers/2000journal/january/2000_jan_8
> > 7-90.pdf
> >
> > With this approach, it was crucial to provide a fast real-time option for
> > the viewshed calculation on relatively large raster DEMs by using only a
> > small memory footprint.
> >
> > The implementation can be found here:
> >
> > https://github.com/szekerest/gdal/blob/viewshed/gdal/alg/viewshed.cpp
> > https://github.com/szekerest/gdal/blob/viewshed/gdal/apps/gdal_viewshed.cpp
> >
> > Does it make sense to spend some more effort and incorporate this approach
> > in GDAL officially?
>
> Sounds useful to me !
> (old memories of having implement line-of-sight based intervisibility
> algorithm in a past life !)

Gdaldem (although it has a different history) has an assortment of DEM
based utilities, https://gdal.org/programs/gdaldem.html  I'm not sure
if it would make sense there or elsewhere.  It would be a useful tool.

Best regards, Eli



>
> Even
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Converting 3D Polygons to 2D Polygons?

[Eli Adam]

On Tue, Oct 15, 2019 at 6:12 PM Brandon Biggs  wrote:

> Hello,
>
> Is there some way to convert 3D objects to 2D polygons using ogr2ogr?
>
>
Did you already try, -dim XY

More details here,
https://gdal.org/programs/ogr2ogr.html#ogr2ogr

What happened if you tried -dim XY?

Best regards, Eli

I have a large file with lots of polygons with 0 as the z coordinate. So
> the point would look like [1,2,0].
>
> I would like it to be: [1,2].
>
> Thanks,
>
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] using gdal_viewshed

[Eli Adam]

Hi Ben,

On Sun, Nov 10, 2019 at 3:57 AM Ben Avrahami  wrote:
>
> Hello all, I've been trying trying to use the newest gdal_viewshed in 
> gdal-dev release, and I've run into an error I can't quite understand.
>
> The input I've been using is:
>
> gdal_viewshed -md 1000 -ox "691868.511" -oy "3492031.487"  
> 

It might be helpful to copy and paste your command so if there are
typos or otherwise, they can be spotted.

A gdalinfo report on your input file could also be helpful.  That
would show coordinates of the image and allow looking at things like
are those coordinates within the image?  Is it in the coordinate
system of the image?  A gdalinfo report details that nicely.

>
> And I get the response:
>
> ERROR 5: C:\temp\files\out.tif, band 1: Access window out of range in 
> RasterIO().  Requested
> (0,-1) of size 67x1 on raster of 67x67.
> ERROR 1: RasterIO error when writing target raster

This makes it seem like something isn't lining up correctly.  With the
absence of information some random guess include: that the coordinate
is not within the image, or perhaps the coordinate is less than -md
1000 units from the edge (although testing that on other data here
worked fine), that there are pixel alignment/resolution issues and
using coordinates not to three decimal places would work better.

I see that gdal_viewshed -md 900 -ox 985710 -oy 658590
http://download.osgeo.org/gdal/data/aaigrid/095b_dem_90m.asc
output2.tif works

and

gdal_viewshed -md 800 -ox 985710 -oy 658590
http://download.osgeo.org/gdal/data/aaigrid/095b_dem_90m.asc
output3.tif fails with the error:

0ERROR 5: output3.tif, band 1: Access window out of range in
RasterIO().  Requested
(0,-1) of size 19x1 on raster of 19x19.
ERROR 1: RasterIO error when writing target raster

it seems that -md must be a multiple of the resolution.

Best regards, Eli

>
> I get a similar error if I try to use the GDALViewshedGenerate C-API 
> function. The input us a valid WGS84-UTM tiff file, and the output is a valid 
> path, but the file does not actually exist until I run the command. After I 
> run the command, the output file is created but only filled halfway. Any help 
> at wall would be appreciated.
>
> regards, Ben
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] How to know which formats allow editing with ogrinfo?

[Eli Adam]

On Fri, Nov 15, 2019 at 3:58 AM Even Rouault  wrote:
>
> On vendredi 15 novembre 2019 08:52:48 CET Rahkonen Jukka (MML) wrote:
> > Hi,
> >
> > Shapefile can be edited with ogrinfo
> > ogrinfo -dialect SQLite -sql "update foo set bar='14'" foo.shp
> >
> > GML opens always as read-only with -sql option
> > ogrinfo -sql "select * from foo" foo.gml
> > Had to open data source read-only.
> > INFO: Open of `foo.gml'
> >   using driver `GML' successful.
> >
> > How can I know which formats support editing with -sql and which not? I
> > could not find any obvious metadata by checking the capabilities of a few
> > different drivers.
>
> There's indeed no driver-level metadata indicating support for updates (update
> through SQL is just a particular case). With a dataset opened, on a layer,
> with the API you can query for fine grain capabilities with
> TestCapability(OLCRandomWrite/OLCDeleteFeature/etc...)

Can this be partly inferred from driver pages with the presence (or
absence) of items?  For instance,
https://gdal.org/drivers/vector/gml.html#driver-capabilities

The old driver pages
(https://web.archive.org/web/20190211030817/https://www.gdal.org/ogr_formats.html)
were tables that very effectively conveyed the capabilities (or
limitations) of the drivers and allowed for scanning for drivers that
had the capabilities that you wanted.  Would a similar table be
possible or desirable?

This got me thinking about the Sphinx migration a bit,
https://lists.osgeo.org/pipermail/gdal-dev/2019-May/050273.html.  It
looks great and the website is easy to use.  Thanks to everyone who
updated that!

There are a few things that might be missing.  The new page has
https://gdal.org/programs/raster_common_options.html#raster-common-options
and https://gdal.org/programs/vector_common_options.html#vector-common-options
I wonder if a list of uncommon options like this would be helpful,
https://trac.osgeo.org/gdal/wiki/ConfigOptions?  Same with some
overview table of driver capabilities?  If it is just a matter of
recreating a new page copied from the old, I would be up trying to
contribute to that.  I lack the detailed knowledge of the drivers to
be able to create it from scratch.

I was also curious to see if the OSGeo technical writing project would
impact any of the documentation.

Best regards, Eli






>
> Even
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] How to know which formats allow editing with ogrinfo?

[Eli Adam]

On Fri, Nov 15, 2019 at 9:55 AM Even Rouault  wrote:
>
> > The old driver pages
> > (https://web.archive.org/web/20190211030817/https://www.gdal.org/ogr_formats
> > .html) were tables that very effectively conveyed the capabilities (or
> > limitations) of the drivers and allowed for scanning for drivers that
> > had the capabilities that you wanted.
>
> The information in individual pages is roughly the same as in the global
> table.
>
> > Would a similar table be possible or desirable?
>
> A few people have indeed noted the absence of the table. Not sure if this is
> usual "resistance to change" phenomenon or if there is there really a strong
> use case for "I don't want which format to use: let's look at the summary page
> to select one".

I've certainly found myself shopping for a format with that table.
Usually some middle format in an ETL toolchain, sometimes complicated
by cross platform considerations for driver availability.

>
> If so, then yes if someone contributes it, that'd be welcome. However I think
> we'd want it to be generated from a Python script from the individual .rst
> pages, by parsing the directives like ".. supports_create::" that are in those
> .rst files. That way that would make maintainance of the summary easier (and
> initial version less tidious that doing that manually)

Contributing it as a python script is an opportunity for someone other
than me.
>
> > There are a few things that might be missing.  The new page has
> > https://gdal.org/programs/raster_common_options.html#raster-common-options
> > and
> > https://gdal.org/programs/vector_common_options.html#vector-common-options
> > I wonder if a list of uncommon options like this would be helpful,
> > https://trac.osgeo.org/gdal/wiki/ConfigOptions?
>
> Migrating the wiki page to the doc could be useful. My own opinion is that
> driver specific configuration options should be documented in the driver
> specific page, rather than in a global config option page. Same with /vsi

I'll try moving some of these over and see how it goes.

> specific options that should go to
> https://gdal.org/user/virtual_file_systems.html if not already there.
>
> Or if a global list is needed, I'd say a bit the same as for driver summaries,
> have a way to compile the list of options from .rst files where they would be
> mention and link from the summary to the actual page. But we don't have
> currently any explicit directive for configuration options.

I'll start with driver specific.

Thanks, Eli

>
> > I was also curious to see if the OSGeo technical writing project would
> > impact any of the documentation.
>
> There was initial discussion but no follow-up as far as GDAL is concerned.
>
> Even
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Doc: driver + config options summary pages [was Re: How to know which formats allow editing with ogrinfo?]

[Eli Adam]

On Sat, Nov 16, 2019 at 9:12 AM Even Rouault  wrote:
>
> > > If so, then yes if someone contributes it, that'd be welcome. However I
> > > think we'd want it to be generated from a Python script from the
> > > individual .rst pages, by parsing the directives like "..
> > > supports_create::" that are in those .rst files. That way that would make
> > > maintainance of the summary easier (and initial version less tidious that
> > > doing that manually)
>
> OK, so I've added two new directives
>
> .. built_in_by_default::
>
> or
>
> .. build_dependencies:: put here dependencies name
>
> and just used them on a couple drivers for demo:
> https://github.com/OSGeo/gdal/commit/0b3b1ed25bdde6f49a6515e0431d78bc9729ff83
>
> A script that fetches all the information from individual pages
> is run automatically at each documentation build and generates a summary table
> at
> https://gdal.org/drivers/raster/index.html
> https://gdal.org/drivers/vector/index.html
>
> ==> What remains to be done is to go through all driver .rst pages and add
> .. built_in_by_default:: or .. build_dependencies:: where appropriate so that
> no "???" remains
>
> Volunteers ?

If the old table is a reliable source, I can do a good portion of them.

>
> > > Migrating the wiki page to the doc could be useful. My own opinion is that
> > > driver specific configuration options should be documented in the driver
> > > specific page, rather than in a global config option page. Same with /vsi
>
> I've also added a specific role when you use a configuration option
>
> :decl_configoption:`FOO`
>
> Example of use:
>
> https://github.com/OSGeo/gdal/commit/c8fcb6d941c0251219dbd57f701e5b161ce5085e
>
> Similarly to the driver list, a script is run at each build to generate an
> index of declared configuration options (if several pages declare the same
> config option, several links will be created). The result is there:
>
> https://gdal.org/user/configoptions_index.html
>
> ==> What remains to be done is tag appropriately configuration options
> wherever they are already mentionned and add missing ones.
>
> Volunteers ?

I can work on some already mentioned ones.

Thanks for adding this.

Best regards, Eli

>
> Even
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] New OGR driver: Imageset

[Eli Adam]

At one point I used GDAL's ability to access EXIF data along with sed
and bash to make a shapefile photo index, like ogrtindex but for
photos and points rather than geo-rasters and polygons.  It worked ok
but had precision issues and I stopped working on it when I found
GPSPrune, http://activityworkshop.net/software/gpsprune/index.html,
which did what I wanted but better.

I think that this would be a useful utility.

Eli

On Mon, Jul 23, 2012 at 8:26 AM, Daniel Morissette
 wrote:
> If I understand correctly, in the Open() call, this driver would open each
> image file to read its EXIF info and index the files in memory? This would
> work fine with a dozen images, but as the number of images increases the
> performance will suffer a lot and this would become unusable in apps such as
> MapServer, and even for Desktop apps with hundreds of images.
>
> If I needed this kind of functionality myself I would use a script to create
> an OGR point file as suggested by Even, to avoid the overhead caused by
> opening all the images.
>
> My 0.02$
>
> Daniel
>
>
>
> On 12-07-23 5:27 AM, Tamas Szekeres wrote:
>>
>> Hi Even,
>>
>> I just want to use the directory name to define the connection to the
>> images, we could also provide to scan the files in subdirectories if
>> needed. I would prefer to have a new driver not just an offline tool for
>> creating OGR datasets, in this case many existing applications (like
>> MapServer) would be capable to utilize this feature.
>> I could imagine a driver configuration file to specify which driver
>> should be used for a particular image format and where the specific
>> information is located, I don't require to harmonize the metadata
>> structure at this time. We should probably allow mixing jpegs and tiffs
>> in the same directory, but the configuration should specify how the
>> similar attributes are provided by each (sub)driver.
>>
>> Best regards,
>>
>> Tamas
>>
>>
>>
>> 2012/7/23 Even Rouault > >
>>
>>
>> Le lundi 23 juillet 2012 09:51:14, Tamas Szekeres a écrit :
>>  > Hi All,
>>  >
>>  > We're thinking about implementing a new OGR driver which would
>> represent a
>>  > set of images as a vector data source. The images are taken from
>> any GPS
>>  > compatible mobile device, and each picture would be represented
>> as a point
>>  > feature, the positions would be extracted from the exif
>> information. The
>>  > file name and path would be provided as an attribute for each
>> feature. This
>>  > data source could then be used by higher level apps to provide
>> symbols at
>>  > the picture locations in the map and display the picture when the
>> feature
>>  > is selected. The driver would definitely use GDAL to extract
>> information
>>  > about the provided images.
>>  >
>>  > I'm not sure whether we already have some kind of alternative
>> solution to
>>  > this, let me know if you know about any. Further ideas about this
>> topic
>>  > would also be helpful.
>>
>> The JPEG driver already exposes EXIF information if found :
>>
>> $ gdalinfo ../autotest/gdrivers/data/albania.jpg
>> Driver: JPEG/JPEG JFIF
>> Files: ../autotest/gdrivers/data/albania.jpg
>> Size is 361, 260
>> Coordinate System is `'
>> Metadata:
>> [...]
>>EXIF_GPSLatitude=(41) (1) (22.91)
>>EXIF_GPSLatitudeRef=N
>>EXIF_GPSLongitude=(19) (55) (42.35)
>>EXIF_GPSLongitudeRef=E
>> [...]
>>
>> $ gdalinfo ../autotest/gcore/data/exif_and_gps.tif -mdd EXIF
>> Driver: GTiff/GeoTIFF
>> Files: ../autotest/gcore/data/exif_and_gps.tif
>> Size is 1, 1
>> Coordinate System is `'
>> [..]
>> Metadata (EXIF):
>> [...]
>>EXIF_GPSLatitude=(77) (5) (60)
>>EXIF_GPSLatitudeRef=S
>>EXIF_GPSLongitude=(34) (12) (0)
>>EXIF_GPSLongitudeRef=E
>> [..]
>>
>> Are you thinking to other raster formats to extract EXIF info from?
>> To my
>> knowledge, the JPEG driver, and recently the GTiff driver, are the
>> only one
>> that extract EXIF for now. I see that the JPEG driver exposes it in
>> the
>> default metadata domain, whereas I chose EXIF for the GTiff driver.
>> For GTiff,
>> the specific EXIF metadata domain seemed better to me to avoid
>> 'polluting' the
>> default metadata domain, but I didn't want to change the JPEG driver
>> at that
>> point. But this would probably requires some harmonization.
>>
>> So with some scripting, you could create for example a point
>> shapefile, with
>> the filename as attribute and GPS position as geometry.
>>
>> In its syntax, this could be something similar to gdaltindex.
>>
>> Doing that as a OGR driver would be also doable of course. The only
>> point to
>> solve is the definition of the connexion string to specify the image
>> set.
>>
>>  

Re: [gdal-dev] gdalbuildvrt problem with heterogenous band characteristics

[Eli Adam]

> Band 1 Block=5000x1 Type=Int16, ColorInterp=Gray
...
> Band 1 Block=1x1 Type=Float32, ColorInterp=Gray
>
> I can't see anything obvious why these two files can't be mosaiced..
>

It looks like one is 16 bit and the other 32.  gdalbuildvrt probably
can't determine the type of output to create.

What is the output type of gdalwarp on the same files? Did gdalwarp do
anything to make the input files match in the output?

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

Re: [gdal-dev] How to cut a Raster map with a KML file

[Eli Adam]

Luis,

On Wed, Sep 5, 2012 at 3:00 AM, Luis Lisboa  wrote:
> Thank you Chitanya.
> But it created an output file with two layers (one with the values from
> original file and another with a 255 for the pixels thar are inside KMZ
> file: How can I have produce one layer?

I may be thinking of something else based on your description.  If you
got an output that has the original values in the area of the kmz and
an alpha mask band over the other areas I think that would be
expected.  You can also use -crop_to_cutline to remove that 'extra'
data.

If that isn't what you are talking about, you may want to use ogr2ogr
to convert your kmz to a shapefile in the same projection as your
input raster and see if it gives you a better result.

Bests, Eli


> Thanks
> Luis
> On Mon, Sep 3, 2012 at 5:10 PM, Chaitanya kumar CH 
> wrote:
>>
>> Luis,
>>
>> gdalwarp has some options for this exact purpose.
>> The cutline can be from any of the OGR readable datasource.
>>
>> http://www.gdal.org/gdalwarp.html
>>
>> On Mon, Sep 3, 2012 at 9:34 PM, Luis Lisboa 
>> wrote:
>>>
>>> Greetings
>>> I have a raster file (Geotiff) and I have a KML file with a polygon and I
>>> want to cut raster map to only have valid values inside the polygon. How can
>>> I do this using just GDAL?
>>>
>>> Usually I used to cut geotiff file with gdalwarp and but in those cases I
>>> was cutting a square (xmin xmax ymin ymax) and in this case is a more
>>> complex polygon
>>>
>>> Thanks
>>> Regards,
>>> Luis
>>>
>>> ___
>>> gdal-dev mailing list
>>> gdal-dev@lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>>
>>
>>
>> --
>> Best regards,
>> Chaitanya kumar CH.
>>
>> +91-9494447584
>> 17.2416N 80.1426E
>
>
>
> ___
> 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

Re: [gdal-dev] How to cut a Raster map with a KML file

[Eli Adam]

Luis,
On Tue, Sep 11, 2012 at 11:14 AM, Luis Lisboa  wrote:
> Hi Eli
> Probably I was not clear: When I use this it outputs a geotiff with two
> bands: 1 with the real data and another one with the mask of the pixels that
> fall inside each polygon. I just want to have an output file with one band
> (band 1) and without the mask. Is it possible?

Sometime images can clean up just be running them through
gdal_translate.  -ot or -b or -mask or some combination may
additionally be needed.  http://gdal.org/gdal_translate.html  Does
gdal_translate on your file collapse the mask band into a single band
with no data values?

rgb2pct.py can be used to convert RGB/RGBA to single band with a color
table.  I'm not sure if it would work with a two band image, one being
the mask but you can try it and see what it does.

HTH, Eli


> Thanks
> Luis
>
>
>
> On Thu, Sep 6, 2012 at 4:50 AM, Eli Adam  wrote:
>>
>> Luis,
>>
>> On Wed, Sep 5, 2012 at 3:00 AM, Luis Lisboa 
>> wrote:
>> > Thank you Chitanya.
>> > But it created an output file with two layers (one with the values from
>> > original file and another with a 255 for the pixels thar are inside KMZ
>> > file: How can I have produce one layer?
>>
>> I may be thinking of something else based on your description.  If you
>> got an output that has the original values in the area of the kmz and
>> an alpha mask band over the other areas I think that would be
>> expected.  You can also use -crop_to_cutline to remove that 'extra'
>> data.
>>
>> If that isn't what you are talking about, you may want to use ogr2ogr
>> to convert your kmz to a shapefile in the same projection as your
>> input raster and see if it gives you a better result.
>>
>> Bests, Eli
>>
>>
>> > Thanks
>> > Luis
>> > On Mon, Sep 3, 2012 at 5:10 PM, Chaitanya kumar CH
>> > 
>> > wrote:
>> >>
>> >> Luis,
>> >>
>> >> gdalwarp has some options for this exact purpose.
>> >> The cutline can be from any of the OGR readable datasource.
>> >>
>> >> http://www.gdal.org/gdalwarp.html
>> >>
>> >> On Mon, Sep 3, 2012 at 9:34 PM, Luis Lisboa 
>> >> wrote:
>> >>>
>> >>> Greetings
>> >>> I have a raster file (Geotiff) and I have a KML file with a polygon
>> >>> and I
>> >>> want to cut raster map to only have valid values inside the polygon.
>> >>> How can
>> >>> I do this using just GDAL?
>> >>>
>> >>> Usually I used to cut geotiff file with gdalwarp and but in those
>> >>> cases I
>> >>> was cutting a square (xmin xmax ymin ymax) and in this case is a more
>> >>> complex polygon
>> >>>
>> >>> Thanks
>> >>> Regards,
>> >>> Luis
>> >>>
>> >>> ___
>> >>> gdal-dev mailing list
>> >>> gdal-dev@lists.osgeo.org
>> >>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> Best regards,
>> >> Chaitanya kumar CH.
>> >>
>> >> +91-9494447584
>> >> 17.2416N 80.1426E
>> >
>> >
>> >
>> > ___
>> > 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

Re: [gdal-dev] gdalwarp with packbits compression: output too large

[Eli Adam]

Rutger,

There are some notes on this on the wiki too,
http://trac.osgeo.org/gdal/wiki/UserDocs/GdalWarp#GeoTIFFoutput-coCOMPRESSisbroken

Regards, Eli

On Thu, Sep 13, 2012 at 8:16 AM, Rutger  wrote:
> Thanks for the tip, i wasn't aware of the -wo flags. Im testing it right now,
> but at 20% its already taking 20 minutes, so its certainly not very
> practical, but im curious of the result.
>
> For comparison, the earlier mentioned gdalwarp operation takes 72 seconds,
> running gdal_translate after it takes another 11 seconds. :)
>
> I noticed some bugfixes from 5 and 6 years ago mentioning compression and
> gdalwarp, but for a case of lots of small files. Maybe that would be a
> situation where the extra flag would be useful.
>
>
> Regards,
> Rutger
>
>
>
>
>
> --
> View this message in context: 
> http://osgeo-org.1560.n6.nabble.com/gdalwarp-with-packbits-compression-output-too-large-tp5001731p5001737.html
> Sent from the GDAL - Dev mailing list archive at Nabble.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

Re: [gdal-dev] clipping multiple shapefiles from a set of clipping polygons

[Eli Adam]

On Tue, Oct 9, 2012 at 3:41 AM, maning sambale
 wrote:
> I see, is there a scripting workaround using 1.9?

ogr2ogr has various -clip. options.  It looks like you could
specify using a particular feature in the AdminPoly to do this
(presumably GEOS support is required?).

ogr2ogr -f "ESRI shapefile" output.shp input.shp -clipsrc
AdminPoly.shp -clipsrclayer AdminPoly -clipsrcsql "SELECT * FROM
AdminPoly WHERE AttributeName_in_AdminPoly='Some_value'"

If you don't have other requirements for the stable release, there are
lots of binaries including nightly builds for some platforms,
http://trac.osgeo.org/gdal/wiki/DownloadingGdalBinaries

HTH, Eli


>
> On Mon, Oct 8, 2012 at 9:14 PM, Etienne Tourigny
>  wrote:
>> generally speaking new features do not go into current stable version
>> (1.9), they will be incorporated into next stable version (probably
>> 2.0).
>>
>> Etienne
>>
>> On Mon, Oct 8, 2012 at 9:57 AM, Ari Jolma  wrote:
>>> On 10/08/2012 03:21 PM, maning sambale wrote:
>>>
>>> Thanks! Is this implemented already in the stable build?
>>>
>>>
>>> It's currently only in the trunk version.
>>>
>>> Ari
>>>
>>>
>>> Maning Sambale (mobile)
>>>
>>> On Oct 8, 2012 7:28 PM, "Ari Jolma"  wrote:

 On 10/08/2012 02:13 PM, maning sambale wrote:
>
> HI,
>
> I have a shapefile polygon that contains administrative boundaries and
> a several shapefile of various features.  I want to create separate
> shapefiles of each layer feature for each administrative boundaries in
> the clipping layer.
>
> For example,
>
> AdminPoly1
>   - AdminPoly1_point.shp
>   - AdminPoly1_line.shp
>   - AdminPoly1_poly.shp
>
> AdminPoly2
>   - AdminPoly1_point.shp
>   - AdminPoly1_line.shp
>   - AdminPoly1_poly.shp
>
> and so on.
>
> Any advice?


 Maning,

 The new layer methods may be what you're looking for:
 http://trac.osgeo.org/gdal/wiki/LayerAlgebra

 Ari

>

 ___
 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
>
>
>
> --
> cheers,
> maning
> --
> "Freedom is still the most radical idea of all" -N.Branden
> wiki: http://esambale.wikispaces.com/
> blog: http://epsg4253.wordpress.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

Re: [gdal-dev] ORA-01406 error when reading many attributes from Oracle

[Eli Adam]

Jukka,

> Could it be possible that OCI driver reserves too little of some resourses and
> fails because of that with large records?  I am now running a query with 
> minimum
> set of columns in my query and ogr2ogr is running well and I believe it will
> convert all the million rows from the view now.
>
> The view schema does not look extra hard for me. There are 21 attributes in 
> the
> view and the longest VARCHAR2 is just 100 chararters long.

This may be overly simplistic, but does the cast operator do anything?

SELECT *, CAST(OGR_STYLE AS character(255)) FROM rivers

Eli

>
> -Jukka Rahkonen-
>
> ___
> 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

Re: [gdal-dev] Absolutely no progress trying to compile GDAL with Oracle support on Windows

[Eli Adam]

On Tue, Nov 27, 2012 at 5:04 PM, cheesybiscuits
wrote:

> Jukka - Thanks for the suggestion. I have extracted the contents of
> release-1600-gdal-mapserver.zip ("Compiled binaries in a single .zip
> package" ) which seems to include the Oracle plugin (gdal_GEOR.dll and
> ogr_OCI.dll).
>
>
Typically to use any of these distributions, you need to run the .bat file
to establish the proper environment settings.  Did you run SDKShell.bat or
similar in the shell before trying to use it?  Often, that .bat only sets
it for the duration and context of that shell.




> However OCI is still not listed in gdalinfo --formats, and running my
> original ogr2ogr command still fails due to not having the right driver.
>
>
You might want to also run gdalinfo --version to see if you are indeed
running what you think you are running instead of some other installation
that may be on your computer.

HTH, Eli


> Is anything special required to enable / load these plugins when using gdal
> tools? I assume this is the case because I also don't see the FGDB format
> listed which is also supposed to be included.
>
> Thanks again
>
>
>
> --
> View this message in context:
> http://osgeo-org.1560.n6.nabble.com/Absolutely-no-progress-trying-to-compile-GDAL-with-Oracle-support-on-Windows-tp5018926p5019194.html
> Sent from the GDAL - Dev mailing list archive at Nabble.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

Re: [gdal-dev] gdalwarp cutline layer for USGS GeoPDF maps

[Eli Adam]

On Fri, Jan 18, 2013 at 2:53 PM, Even Rouault
 wrote:
> Le vendredi 18 janvier 2013 23:43:39, Kris Andersen a écrit :
>> I'm having trouble using the -crop_to_cutline option in gdalwarp to remove
>> whitespace around USGS topo maps. These maps are in the GeoPDF format, and
>> contain a NEATLINE metadata value that is suppose to provide the
>> information to crop the image. I thought I could do this using the -cl
>> flag,
>>
>> gdalwarp -crop_to_cutline -cl NEATLINE VA_Strasburg_20110524_TM_geo.pdf
>> test.tiff
>>
>> but that didn't work. I still see lots of whitespace, and the image looks
>> oddly skewed.
>
> See http://osgeo-org.1560.n6.nabble.com/gdal-dev-GeoPDF-translation-
> tt3742508.html#a3742510

Some info also on the wiki, http://trac.osgeo.org/gdal/wiki/USGS_PDF_Topo

Eli


> ___
> 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

Re: [gdal-dev] gdalwarp cutline layer for USGS GeoPDF maps

[Eli Adam]

On Fri, Jan 18, 2013 at 4:08 PM, Kris Andersen  wrote:
> Thanks for the quick replies!
>
> I'm still having trouble, but maybe I don't know what the final cropped image 
> should look like? I was thinking all the whitespace and USGS margin info 
> would be removed?

That is what I would expect too.

>
> When I follow the directions from
>
>   http://trac.osgeo.org/gdal/wiki/USGS_PDF_Topo
>
> I get the output
>
>   http://biciworks.com/OR_Newport_North_20110824_TM_geo.tiff
>   (warning! 32 MB download)
>
> This still seems to have lots of whitespace and margin content, although it 
> is skewed from the original. Is this the right result?

I did the same thing and got the same result.  If you make a shapefile
out of the neatline and view it, you will see that it matches to the
black.  So it is a correct result but not intended.  So we need
different values for the neatline.  Here are values that I just
estimated off of QGIS:

"Record_Id","wkb_Polygon"
"1","POLYGON ((420793 4955647,420689 4941858,410784 4942004,410971 4955792))"

Using this gives expected results.

Does this pdf file have incorrect neatline information?  I'll look at
some others to see if they work better.

>
> This was done using
>
> $ gdalwarp -cutline wkt_cutline_file.vrt -cl NEATLINE -crop_to_cutline 
> OR_Newport_North_20110824_TM_geo.pdf OR_Newport_North_20110824_TM_geo.tiff
>
> with wkt_cutline_file.vrt and NEATLINE.csv copied from the Wiki.
>
> When I try the same command with the GeoPDF I linked to, all I get is an ugly 
> black square. This is after changing NEATLINE.csv accordingly with the 
> metadata from VA_Strasburg_20110524_TM_geo.pdf, specifically,
>
> NEATLINE.csv
> "Record_Id","wkb_Polygon"
> "1","POLYGON ((739349.486192459356971 
> 4305760.633085563778877,726989.596524115651846 
> 4305396.499421719461679,726535.950552191701718 
> 4320794.730121357366443,738895.840220535406843 
> 4321158.863785205408931,739349.486192459356971 4305760.633085563778877))"
>
> I noticed the mailing list post pays particular attention to GDAL_PDF_DPI.
>
> $ gdalwarp -crop_to_cutline -cutline $i.csv -co "GDAL_PDF_DPI=250" -of GTiff  
> $i $i.tiff
>
> If I'm not mistaken, I think this line should be
>
> $ gdalwarp -crop_to_cutline -cutline $i.csv --config GDAL_PDF_DPI 250 -of 
> GTiff  $i $i.tiff

I think you are correct but I'm not certain.

>
> Regardless, setting the resolution to 250 dpi doesn't help matters for me. I 
> also tried 400 and 508 dpi, which is what USGS claims the high-resolution 
> scans are, but that was also a dead end.
>
> Any ideas what's going on here?
>
> One thing: I did notice my output of gdalinfo --formats is slightly different 
> from the Wiki. Could this have anything to do with it?

I don't think that matters but is a result of a recent reformatting of
the output, http://lists.osgeo.org/pipermail/gdal-dev/2013-January/035200.html
has more.

HTH, Eli

>
> $ gdalinfo --formats | grep PDF
>   PDF (rwvs): Geospatial PDF
>
> The Wiki has "PDF (rov): Geospatial PDF".
>
> Thanks,
>
>   Kris
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Neatline for USGS PDF maps

[Eli Adam]

Checking over some USGS topo PDFs, the neatline reported appears too
large.  Has anyone else check this or noticed anything similar?
Specific details below.


> I did the same thing and got the same result.  If you make a shapefile
> out of the neatline and view it, you will see that it matches to the
> black.  So it is a correct result but not intended.  So we need
> different values for the neatline.  Here are values that I just
> estimated off of QGIS:
>
> "Record_Id","wkb_Polygon"
> "1","POLYGON ((420793 4955647,420689 4941858,410784 4942004,410971 4955792))"
>
> Using this gives expected results.
>
> Does this pdf file have incorrect neatline information?  I'll look at
> some others to see if they work better.
>

It looks to me that the USGS topo pdf from
http://ims.er.usgs.gov/gda_services/download?item_id=5365522 reports a
neatline that covers most of the pdf, NEATLINE=POLYGON
((421614.539994676539209
4956417.675689895637333,421413.787766160559841
4941008.479600958526134,409984.382813899661414
4941157.382794972509146,410185.135042413836345
4956566.578883905895054,421614.539994676539209
4956417.675689895637333)) but should cover much less area as estimated
out of QGIS above.

Is this an error within the file or an error in what gdalinfo reports
or something else?  If it is an error in the file, I can contact the
USGS liaison for the Pacific Northwest to see if it can be fixed (at
least for Oregon).

I checked other USGS Topos in OR, CO, MI and found the same problem.
I tried some in ND and IA and the neatline seemed correct.
Specifically, 
http://ims.er.usgs.gov/gda_services/download?item_id=5154397&quad=Granger&state=IA&grid=7.5X7.5&series=TNM%20GeoPDF
and 
http://ims.er.usgs.gov/gda_services/download?item_id=5251428&quad=Nelson%20Lake&state=ND&grid=7.5X7.5&series=TNM%20GeoPDF

It is great to have the pdf driver to make more data accessible.
GDAL/OGR always makes me smile when I encounter data in some new to me
format and it is already supported (in the last few months, SEG-Y).

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

Re: [gdal-dev] ogr2ogr convert e00 to shp

[Eli Adam]

Murat,

> I was creating shp file using ogr2ogr as follows
>
> avcimport file.e00 coverage
>
> ogr2ogr -f "ESRI Shapefile" file.shp coverage
>
> This was worked well for old version of gdal
>
> I have installed gdal 1.9 then I have faced such a problem
>
> the ogr2ogr command create a directory and shp file located unter that
> directory.
> But old version of ogr2ogr was created files under the same directory where
> you work

I think that ogr2ogr has (sometimes) created shapefiles in directories
for a long time before 1.9.

>
> the old version of ogr2ogr creates file.shp file.shx file.dbf
>
> but new version create directory under working directory called file.shp
> instead of file.shp file
> and the shp files located under file.shp directory
>
> Please let me know what is differs this resuts.
>
> Regards
> Murat

The shapefile driver page talks about this some,
http://gdal.org/ogr/drv_shapefile.html

I notice similar things (this is with PostGIS datasource).  If the
output shp file is the same name as input source then the shp is
created in the specified directory.  If it is a different name, then I
get a directory.

ogr2ogr V:\Data\E_addendum\Assessor\2012\nbhd\nbhd_codes_2012_postgis2.shp
PG:"host=123.12.12.12 user=username dbname=mydatabase
password=mypassword" taxlots2012_union_valid_nbhd_codes_v1 -a_srs
"EPSG:2913"

creates a directory and then the shp (and the shp has the name of the
original datasource), i.e.
V:\Data\E_addendum\Assessor\2012\nbhd\nbhd_codes_2012_postgis2.shp\taxlots2012_union_valid_nbhd_codes_v1.dbf,
.shp, etc

ogr2ogr 
V:\Data\E_addendum\Assessor\2012\nbhd\taxlots2012_union_valid_nbhd_codes_v1.shp
PG:"host=123.12.12.12 user=username dbname=mydatabase_template
password=mypassword" taxlots2012_union_valid_nbhd_codes_v1 -a_srs
"EPSG:2913"

creates the named shp in the directory.

I have occasionally found this a minor annoyance.  Is there a config
or creation option to change this?  A search of the email archives
didn't turn anything up for me.

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

[gdal-dev] TIFFMergeFieldInfo error when adding overviews to large tiff

[Eli Adam]

Hi all,

I'm adding internal overviews to a ~20G tiff file and I get this error
(1000+ times):
gdaladdo topo_mosaic_4326.tif 2 4 8 16 32 64 128 256 512 1024 --config
COMPRESS_OVERVIEW PACKBITS
ERROR 1: topo_mosaic_4326.tif:Failed to allocate memory for for fields
array (1410046 elements of 16 bytes each)
gdaladdo still completes and the file seems to work fine.  What does
that error mean?  Does it impact the output file or overviews?  Is
there a different way I should approach this?  Are there any general
rules for which compression to select?  I've found JPEG-In-TIFF, using
PHOTOMETRIC=YCBCR to work very well for RGB, but otherwise I'm unsure
of the best compression for the type of raster (in this case single
band, byte, colormap).

I just checked my version and I am running 1.9.0 on a older modest XP
laptop (I figured that I would have been running something more
recent).  I can try again with a nightly or compile on Ubuntu or use a
computer with more resources (the process takes a long time to run, so
reporting back on those will take some time).

Here is information (I've omitted some previous mosaicing and
reprojecting) of how I got to this point and some gdalinfo reports:
gdal_translate mosaic_4326.vrt topo_mosaic_4326.tif -co
COMPRESS=PACKBITS -co TILED=YES -co BIGTIFF=YES --config GDAL_CACHEMAX
400

gdaladdo topo_mosaic_4326.tif 2 4 8 16 32 64 128 256 512 1024 --config
COMPRESS_OVERVIEW PACKBITS
ERROR 1: topo_mosaic_4326.tif:Failed to allocate memory for for fields
array (1410046 elements of 16 bytes each)

original input files:
>gdalinfo ID_Cuddy_Mountain_20110715_TM_geo.tif
Driver: GTiff/GeoTIFF
Files: ID_Cuddy_Mountain_20110715_TM_geo.tif
Size is 4880, 6845
Coordinate System is:
PROJCS["NAD83 / UTM zone 11N",
GEOGCS["NAD83",
DATUM["North_American_Datum_1983",
SPHEROID["GRS 1980",6378137,298.2572221010002,
AUTHORITY["EPSG","7019"]],
AUTHORITY["EPSG","6269"]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433],
AUTHORITY["EPSG","4269"]],
PROJECTION["Transverse_Mercator"],
PARAMETER["latitude_of_origin",0],
PARAMETER["central_meridian",-117],
PARAMETER["scale_factor",0.9996],
PARAMETER["false_easting",50],
PARAMETER["false_northing",0],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]],
AUTHORITY["EPSG","26911"]]
Origin = (509873.30982669181,4969095.03341848590)
Pixel Size = (2.032010116947724,-2.032010116947745)
Metadata:
  AREA_OR_POINT=Area
Image Structure Metadata:
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  (  509873.310, 4969095.033) (116d52'30.00"W, 44d52'30.74"N)
Lower Left  (  509873.310, 4955185.924) (116d52'30.97"W, 44d44'59.97"N)
Upper Right (  519789.519, 4969095.033) (116d44'58.04"W, 44d52'30.00"N)
Lower Right (  519789.519, 4955185.924) (116d44'59.99"W, 44d44'59.23"N)
Center  (  514831.415, 4962140.479) (116d48'44.75"W, 44d48'45.05"N)
Band 1 Block=4880x1 Type=Byte, ColorInterp=Palette
  NoData Value=195
  Color Table (RGB with 256 entries)
0: 0,0,0,255
1: 128,0,0,255
2: 0,128,0,255
3: 128,128,0,255
...
  254: 0,255,255,255
  255: 255,255,255,255

final output file with overviews:
>gdalinfo -checksum topo_mosaic_4326.tif
Driver: GTiff/GeoTIFF
Files: topo_mosaic_4326.tif
Size is 398449, 210532
Coordinate System is:
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.257223563,
AUTHORITY["EPSG","7030"]],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433],
AUTHORITY["EPSG","4326"]]
Origin = (-124.732439702451200,46.380533997595272)
Pixel Size = (0.20993062915,-0.20993062915)
Metadata:
  AREA_OR_POINT=Area
Image Structure Metadata:
  COMPRESSION=PACKBITS
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  (-124.7324397,  46.3805340) (124d43'56.78"W, 46d22'49.92"N)
Lower Left  (-124.7324397,  41.9608225) (124d43'56.78"W, 41d57'38.96"N)
Upper Right (-116.3677748,  46.3805340) (116d22' 3.99"W, 46d22'49.92"N)
Lower Right (-116.3677748,  41.9608225) (116d22' 3.99"W, 41d57'38.96"N)
Center  (-120.5501072,  44.1706782) (120d33' 0.39"W, 44d10'14.44"N)
Band 1 Block=256x256 Type=Byte, ColorInterp=Palette
  Checksum=45365
  NoData Value=195
  Overviews: 199225x105266, 99613x52633, 49807x26317, 24904x13159, 12452x6580, 6
226x3290, 3113x1645, 1557x823, 779x412, 390x206
  Overviews checksum: 27605, 16665, 58099, 63342, 4876, 64021, 44152, 14528, 574
63, 15006
  Color Table (RGB with 256 entries)
0: 0,0,0,255
1: 128,0,0,255
2: 0,128,0,255
3: 128,128,0,255
...
  253: 255,0,255,255
  254: 0,255,255,255
  255: 255,255,255,255

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

Re: [gdal-dev] TIFFMergeFieldInfo error when adding overviews to large tiff

[Eli Adam]

Even,

Thanks for checking into this and the ideas.

Eli

On Tue, Apr 16, 2013 at 10:18 AM, Even Rouault
 wrote:
> Le lundi 15 avril 2013 23:47:33, Eli Adam a écrit :
>> Hi all,
>>
>> I'm adding internal overviews to a ~20G tiff file and I get this error
>> (1000+ times):
>> gdaladdo topo_mosaic_4326.tif 2 4 8 16 32 64 128 256 512 1024 --config
>> COMPRESS_OVERVIEW PACKBITS
>> ERROR 1: topo_mosaic_4326.tif:Failed to allocate memory for for fields
>> array (1410046 elements of 16 bytes each)
>> gdaladdo still completes and the file seems to work fine.  What does
>> that error mean?  Does it impact the output file or overviews?  Is
>> there a different way I should approach this?  Are there any general
>> rules for which compression to select?  I've found JPEG-In-TIFF, using
>> PHOTOMETRIC=YCBCR to work very well for RGB, but otherwise I'm unsure
>> of the best compression for the type of raster (in this case single
>> band, byte, colormap).
>
> That's interesting. I've tried to reproduce your setup with an artificial 
> blank
> input file of the same dimensions and here's what I get (after several hours):
>
> $ gdaladdo topo_mosaic_4326.tif 2 4 8 16 32 64 128 256 512 1024 --config
> COMPRESS_OVERVIEW PACKBITS
> 0...10...20...30...40...50...60...70...80...90...100 - done.
> Current VSI memory usage: 0 bytes
> Maximum VSI memory usage: 2361761086 bytes
> Number of calls to VSIMalloc()  : 43981823
> Number of calls to VSICalloc()  : 1259
> Number of calls to VSIRealloc() : 17378556
> Number of calls to VSIFree(): 43983082
> VSIMalloc + VSICalloc - VSIFree : 0
>
> The interesting part is the memory usage report. It is based on an
> instrumented version of GDAL that instruments each memory allocation routine.
> This is with the internal version of libtiff that redirects the TIFF memory
> allocation routines to the GDAL ones. So apparently there wouldn't be a memory
> leak (some valgrind'ing should be done on a smaller file to confirm), but a
> maximum memory usage of 2.3 GB ! No wonder why it fails on a Windows 32 bit
> (my test was done a Linux 64bit). I'm not sure why such a high memory use
> occurs. Some investigation should be done.
>
> As far as the error message you've seen, I wouldn't swear that there's not
> some pixel corruption in the result you get...
>
> As a potential track for a workaround (completely untested), perhaps you could
> try to do :
>
> $ gdaladdo topo_mosaic_4326.tif 2 --config COMPRESS_OVERVIEW PACKBITS
> $ gdaladdo topo_mosaic_4326.tif 4 --config COMPRESS_OVERVIEW PACKBITS
> $ gdaladdo topo_mosaic_4326.tif 8 --config COMPRESS_OVERVIEW PACKBITS
> $ gdaladdo topo_mosaic_4326.tif 16 --config COMPRESS_OVERVIEW PACKBITS
> etc..
>
>
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] TIFFMergeFieldInfo error when adding overviews to large tiff

[Eli Adam]

On Tue, Apr 16, 2013 at 2:11 PM, Even Rouault
 wrote:
> I've investigated a bit and I've discovered that while computing overviews,
> libtiff constantly switches from TIFF "directories" (main image, first
> overview,second overview, etc...). While doing this, it calls each time client
> code to install its own TIFF tags (libgeotiff for the geotiff tags, GDAL for 
> the
> GDAL specific TIFF tags), but doesn't reset its array of existing tags. So 
> each
> time the tags are added again and again, hence the huge memory allocation.
>
> Could you test the attached patch (assuming you build GDAL with internal
> libtiff) ?

I can apply and test this on linux but don't know how to do it on
windows.  I usually use the nightly windows builds from Tamas.  Should
I test this on linux?

>
> It would be good if you could also open a ticket in Trac about that issue.

I've opened a ticket, http://trac.osgeo.org/gdal/ticket/5054

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

Re: [gdal-dev] Neatline for USGS PDF maps

[Eli Adam]

I found this in drafts and it appears I failed to send it.  Sorry for
delay.  Sent partly for the list archives at this point.

On Sat, Jan 19, 2013 at 8:14 AM, Even Rouault
 wrote:
>> Looking more closely at those files, I see that there are various
>> registration blocks. The algorithm up to now was to select the
>> registration block whose neatline covered the most area in terms of
>> pixels. In the case of
>> OR_Newport_North_20110824_TM_geo.pdf, those blocks are :
>> "UTM Grid and Projection"
>> "Orthoimage"
>> "Map Layers"
>> "Adjoining Quadrangles Diagram"
>>
>> The number and names of blocks may change, but in all USGS topo PDFs
>> samples I've tried, the "Map Layers" is always present and seems to the
>> one that lead to the best results, so I've just pushed a change to select
>> it when it is found.

--config GDAL_PDF_NEATLINE is very helpful.  Did you find the
registration name blocks with one of the supporting PDF libraries?  Is
it possible to find these multiple registration name blocks from gdal?
 (I tried: gdalinfo --debug on without success.)

Thanks for the many recent improvements for the USGS topo PDFs.
--config GDAL_PDF_RENDERING_OPTIONS is very useful.

>>
>> You can use the following Python script to automate fetching the neatline
>> and launching gdalwarp to use it :
>>
>> 
>>
>> from osgeo import gdal
>> import os
>> import sys
>>
>> ds = gdal.Open(sys.argv[1])
>> neatline_wkt = ds.GetMetadataItem("NEATLINE")
>> ds = None
>>
>> f = open('cutline.csv', 'wt')
>> f.write('id,WKT\n')
>> f.write('1,"%s"\n' % neatline_wkt)
>> f.close()
>>
>> os.system('gdalwarp %s %s.tif ' % (sys.argv[1], sys.argv[1]) +
>>   '-crop_to_cutline -cutline cutline.csv -overwrite')
>>
>> 

This is great.  I've added it to the wiki,
http://trac.osgeo.org/gdal/wiki/USGS_PDF_Topo

>
> If you're interested in only the raster part, let's imagine that the above
> script is called cutline.py, you can try the following :
>
> export GDAL_PDF_RENDERING_OPTIONS=RASTER
> (or set GDAL_PDF_RENDERING_OPTIONS=RASTER on windows)
>
> python cutline.py your.pdf
>
> nearblack your.pdf -o your_rgba.pdf -of GTiff -setalpha -color 0,0,0 \
> -color 255,255,255
>

I interpreted the above as:
nearblack your.tif -o your_rgba.tif -of GTiff -setalpha -color 0,0,0
-color 255,255,255
Where your.tif is the output from cutline.py and your_rgba.tif is the
output from nearblack.

Thanks, Eli


>>
>> Best regards,
>>
>> Even
>> ___
>> 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

Re: [gdal-dev] Merge overviews from multiple files

[Eli Adam]

On Fri, Apr 19, 2013 at 9:47 PM, ryagz  wrote:

> Hi,
>
> I have downloaded some raster data which has given me overview levels as
> different tiff files, how can i merge them into a single tiff file. so that
> when i load that file with gdal proper overviews are picked.
>

If your files are named file.tif, file.tif.ovr, file.tif.ovr.ovr, etc I
think that GDAL will automatically read the overviews.  gdalinfo file.tif
will show if GDAL reports the presence of the overviews.

A VRT could be used to combine the various files then gdal_translate that.
gdal_translate with COPY_SRC_OVERVIEWS=YES could create a single tif with
the overviews (more details, http://www.gdal.org/frmt_gtiff.html).  I'm not
sure if COPY_SRC_OVERVIEWS will work on external overviews.

Eli



>
> Ryagz
>
>
>
> --
> View this message in context:
> http://osgeo-org.1560.x6.nabble.com/Merge-overviews-from-multiple-files-tp5048389.html
> Sent from the GDAL - Dev mailing list archive at Nabble.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

Re: [gdal-dev] Help about GDAL

[Eli Adam]

Edison,

I've had similar problems (although for different reasons I think).  The
suggestions at the end of this are similar to what I've done to make it
work for me,
http://lists.osgeo.org/pipermail/gdal-dev/2009-March/020132.html

Sudo ldconfig might help too.

Regards, Eli
On May 10, 2013 8:38 PM, "edison Qian"  wrote:

> Dear List:
>
> i have met an error about GDAL that when a cpp file including GDAL library
> is coded, i compile this cpp file with following command in ubuntu bash:
>
> $g++ gdal_linux.cpp -I /usr/local/include/ -L /usr/local/lib/ -lgdal
> -o aaa
>
> it succeeds!
> however, when i run file aaa, an error appears:
>
> error while loading shared libraries: libgdal.so.1: cannot open shared
> object file: No such file or directory
>
> which is similar to the one Wesley got:
> http://lists.osgeo.org/pipermail/gdal-dev/2009-March/020128.html
>
> i wonder whether this problem has been solved or not because i've not seen
> any solutions to it.
> Any help would be greatly appreciated.
>
> Kind regards,
> Edison
>
> ___
> 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

Re: [gdal-dev] select shapes in a folder by geometry type

[Eli Adam]

If you are using a recent version can you ignore geometry type and use
the -dim 2 switch?

-dim val:(starting with GDAL 1.10) Force the coordinate dimension to
val (valid values are 2 or 3). This affects both the layer geometry
type, and feature geometries.

Best Regards, Eli


On Fri, May 24, 2013 at 9:23 AM, Pedro Costa  wrote:
> Hi guys,
>
> I'm trying  to make a script that converts 3d shapefiles to 2d.
> I'm using the loop 'for...do'' and this command:
>
> 'ogr2ogr -f "ESRI Shapefile" -nlt POINT 2d_points/$shp $shp'
>
> My problem is that i don't  know how to select only shapefiles of points,
> and next only polygons, and next only lines to put the right geometry in the
> command.
> For example, i have tried the '-where "OGR_GEOMETRY='Point'"'  like that:
>
> ogr2ogr -where "OGR_GEOMETRY='Point'" -f "ESRI Shapefile" -nlt POLYGON
> 2d_poligonos/$shp $shp
>
> But don't work because ogr converts shapefiles of polygons and lines into
> points!
>
> Can anyone tell me how i can select  only shapefiles of points in a folder
> with many shapefiles of many geometry types?
>
> Thanks
> ___
> 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

Re: [gdal-dev] select shapes in a folder by geometry type

[Eli Adam]

> [1] ogr2ogr -f "ESRI Shapefile" -dim 2 pontos_2d.shp ocup_ilegal.shp

Yes just like this.

>
> With this command don't work. I'm using 1.9 version but the '-dim' option
> don't show up if i type  'ogr2ogr --long-usage'.

It is only in GDAL 1.10+ so it will not work in 1.9.

Eli

>
>
> Em 24-05-2013 17:44, Eli Adam escreveu:
>
>> If you are using a recent version can you ignore geometry type and use
>> the -dim 2 switch?
>>
>> -dim val:(starting with GDAL 1.10) Force the coordinate dimension to
>> val (valid values are 2 or 3). This affects both the layer geometry
>> type, and feature geometries.
>>
>> Best Regards, Eli
>>
>>
>> On Fri, May 24, 2013 at 9:23 AM, Pedro Costa 
>> wrote:
>>>
>>> Hi guys,
>>>
>>> I'm trying  to make a script that converts 3d shapefiles to 2d.
>>> I'm using the loop 'for...do'' and this command:
>>>
>>> 'ogr2ogr -f "ESRI Shapefile" -nlt POINT 2d_points/$shp $shp'
>>>
>>> My problem is that i don't  know how to select only shapefiles of points,
>>> and next only polygons, and next only lines to put the right geometry in
>>> the
>>> command.
>>> For example, i have tried the '-where "OGR_GEOMETRY='Point'"'  like that:
>>>
>>> ogr2ogr -where "OGR_GEOMETRY='Point'" -f "ESRI Shapefile" -nlt POLYGON
>>> 2d_poligonos/$shp $shp
>>>
>>> But don't work because ogr converts shapefiles of polygons and lines into
>>> points!
>>>
>>> Can anyone tell me how i can select  only shapefiles of points in a
>>> folder
>>> with many shapefiles of many geometry types?
>>>
>>> Thanks
>>> ___
>>> 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
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Clipping imprecision with gdal_translate

[Eli Adam]

gdalwarp does have -tap which may be of some use.  Quoting the doc page:

-tap:(GDAL >= 1.8.0) (target aligned pixels) align the coordinates of
the extent of the output file to the values of the -tr, such that the
aligned extent includes the minimum extent.


Best Regards, Eli

On Tue, Jun 4, 2013 at 12:35 AM, Ari Jolma  wrote:
> JM,
>
> Looks to me that GDAL has clipped to the nearest pixel boundaries and not to
> the window you have provided. This is probably a feature. Maybe gdalwarp
> would do the kind of resampling you wish, but I'm not sure.
>
> Regards,
>
> Ari
>
>
> On 06/03/2013 03:37 PM, JM wrote:
>
> Hello List.
>
>
>
> At first i wanna thanks for the great work you are doing with the gdal
> library. It is a source of great tools and opportunities for spatial issues
> which whom i involed in.
>
>
>
> Among others i am using the commandline tool gdal_translate for clipping
> raster files via the following example command:
>
>
>
> gdal_translate -projwin 13.664938 53.202428
> 13.834784 53.117686 source.tif target.tif
>
>
>
> The source tif is already georeferenced (EPSG:4326). I would now assume that
> the boundingbox of the following GTiff is somethink like this:
>
>
>
> Lower Left: 13.664938 53.117686
>
> Upper Right: 13.834784 53.202428
>
>
>
> Instead it is something like this (the full gdalinfo dialog you can see in
> the attach to this mail):
>
>
>
> Lower Left: 13.610463 53.1000244672
>
> Upper Right: 13.8333191458 53.2000151873
>
>
>
> So there is a small imprecision in the clipping result. My question is now
> if this imprecision is normal (maybe a result of rounding operations within
> the clipping process) or if i do something wrong (do i miss something in my
> command).
>
>
>
> I am using libgdal1 version 1.9.0-3.1ubunut1. Looking forward to hearing
> from you.
>
>
>
> Kind regards,
>
>
>
> JM
>
>
>
>
>
> ___
> 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
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Working with NTF files

[Eli Adam]

> No (except that I left this option as the "final attempt" of many tests --
> working with some >1GB images here, so it took me hours... :D).  Your
> confirmation, though, is highly useful!
>

Sometimes to avoid materializing large intermediate datasets on disk, a VRT
can be used.  I'm not sure if this would be useful in your case.

> On the GDAL side we often have special info in trac wiki pages under the
> BuildHints page, but in this case the issues are more usage rather than
> building so there is no obvious place for user contributions.  The format
> pages for NITF do have quite a bit of info.  It is (I think) the only
driver
> with an "advanced" page.  However, there are many kinds of NITF
> files and thus usage patterns that are an issue so it isn't clear how to
> handle that in the user docs.

I and others have put GDAL usage notes here,
http://trac.osgeo.org/gdal/wiki/CodeSnippets

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

Re: [gdal-dev] concatenated VRT file

[Eli Adam]

On Tue, Aug 6, 2013 at 2:21 AM, Jan Hartmann  wrote:

> **
> Not sure if this is possible, but perhaps someone here knows a trick.
>
> I use a VRT file as an index to a large set of detailed, tiled scans of
> the Netherlands, built with gdalbuildvrt. I recently discovered how to
> transform this map on the fly, so that it  exactly aligns to older maps in
> different coordinate systems. It's just a matter of adapting the
>  item in the VRT file.
>

I'm not sure if this will work for what you are doing, but I change the
projection of VRT files with gdalwarp: gdalwarp -of VRT -t_srs "+proj=omerc
+lat_0=44.75 +lonc=-124.05 +alpha=5 +k=1 +x_0=134743.33241
+y_0=369139.02771 +ellps=GRS80 +datum=NAD83 +to_meter=0.3048 +no_defs
+wktext" infile.vrt outfile.vrt

Eli


>
> So I can copy the VRT file for every old map, and adapt the 
> in each of them. This means that all VRT files will be identical, except
> for the  line. The VRT files are quite large, because they
> cover lots of tiles. Can anyone here think of a method to do this with one
> central VRT file, in which only the  line is plugged that is
> required for the particular old map?  Something like a symbolic link to
> concatenate the variable and stable parts of the VRT file?
>
> Jan
>
> ___
> 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

Re: [gdal-dev] [EXTERNAL] /vsicurl/ and gz files

[Eli Adam]

There is also more info on the wiki,
http://trac.osgeo.org/gdal/wiki/UserDocs/ReadInZip

Best Regards, Eli

On Thu, Oct 10, 2013 at 11:56 AM, Smith, Michael ERDC-RDE-CRREL-NH
 wrote:
> Jose,
>
> You can use /vsigzip/ with /vsicurl
>
> Try
>
> gdalinfo
> /vsigzip/vsicurl/http://www.globalbedo.org/GlobAlbedo29/tiles/2004/h17v04/GlobAlbedo.2004001.h17v04.nc.gz
>
> Mike
>
> --
> Michael Smith
> Remote Sensing/GIS Center
> US Army Corps of Engineers
>
> From: Jose Gomez-Dans 
> Date: Thursday, October 10, 2013 2:33 PM
> To: gdal-dev 
> Subject: [EXTERNAL] [gdal-dev] /vsicurl/ and gz files
> Resent-From: Michael Smith 
>
> Hi,
>
> I was wondering if it's possible to use /vsitar/ to have a peek in .gz
> files, such as this one:
> http://www.globalbedo.org/GlobAlbedo29/tiles/2004/h17v04/GlobAlbedo.2004001.h17v04.nc.gz
>
> The file is a NetCDF, with 20 different layers. I was hoping to be able to
> read the file in using /vsitar/ (actually, combining /vsicurl/ and
> /vsitar/), but using e.g. /vsitar/GlobAlbedo.2004001.h17v04.nc.gz I get:
>
> $ gdalinfo /vsitar/GlobAlbedo.2004129.h17v04.nc.gz
> ERROR 4: `/vsitar/GlobAlbedo.2004129.h17v04.nc.gz' does not exist in the
> file system,
> and is not recognised as a supported dataset name.
>
> gdalinfo failed - unable to open '/vsitar/GlobAlbedo.2004129.h17v04.nc.gz'.
> GDAL: In GDALDestroy - unloading GDAL shared library.
>
> I also get failures when I try to open remote sample netcdf files using
> /vsicurl/:
>
> $ gdalinfo
> /vsicurl/http://www.unidata.ucar.edu/software/netcdf/examples/tos_O1_2001-2002.nc
> VSICURL:
> GetFileSize(http://www.unidata.ucar.edu/software/netcdf/examples/tos_O1_2001-2002.nc)=2949152
> response_code=200
> VSICURL:
> GetFileList(/vsicurl/http://www.unidata.ucar.edu/software/netcdf/examples)
> VSICURL: Downloading 0-16383
> (http://www.unidata.ucar.edu/software/netcdf/examples/tos_O1_2001-2002.nc)...
> VSICURL: Got reponse_code=206
> GDAL_netCDF:
> =
> calling nc_open(
> /vsicurl/http://www.unidata.ucar.edu/software/netcdf/examples/tos_O1_2001-2002.nc
> )
> ERROR 1: netcdf error #-33 : NetCDF: Not a valid ID .
> at (netcdfdataset.cpp,~netCDFDataset,1446)
>
> GDAL:
> GDALClose(/vsicurl/http://www.unidata.ucar.edu/software/netcdf/examples/tos_O1_2001-2002.nc,
> this=0x1e2ca40)
> gdalinfo failed - unable to open
> '/vsicurl/http://www.unidata.ucar.edu/software/netcdf/examples/tos_O1_2001-2002.nc'.
> GDAL: In GDALDestroy - unloading GDAL shared library.
>
> Questions:
> 1.- Do gzipped files work with /vsitar/?
> 2.- Are remote/compressed netcdf files useable with GDAL?
> 3.- How do you select a particular layer if the answer to (2) is yes?
>
> Thanks for your time!
> Jose
>
>
> ___
> 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

Re: [gdal-dev] In which version utilities have appeared?

[Eli Adam]

On Fri, Nov 8, 2013 at 10:34 AM, Even Rouault
 wrote:
> Le vendredi 08 novembre 2013 19:30:34, Jukka Rahkonen a écrit :
>> Even Rouault  mines-paris.org> writes:
>> > Le vendredi 08 novembre 2013 19:19:35, Jukka Rahkonen a écrit :
>> > > Hi,
>> > >
>> > > Is there a list about the minimum GDAL version for each of the GDAL
>> > > tools in http://www.gdal.org/gdal_utilities.html?

There are not that many utilities, however, many of the utilities have
all kinds of flags and features which started at various versions.
Looking for "starting with gdal" on http://gdal.org/ogr2ogr.html gives
a hint at that complexity.  "starting with" or "GDAL >" on
http://gdal.org/gdal_translate.html   And if there are changes in
formats (or proj4) that interact with these flags... Coherent
presentation would require a huge table or chart and maybe still be
confusing.

$.02, Eli


>> >
>> > Not directly. A solution would be to download the *doc packages on
>> > http://download.osgeo.org/gdal/ and look at the differences
>>
>> Oh dear. And if I bother to do that what might be a good place to share the
>> results? Wiki perhaps? I am writing short tutorials sometimes and it is
>> essential to mension the versions because there are old GDAL versions in
>> the wild and included in other programs.
>
> Well, I admire your energy. Why not being lazy and telling that your tutorial
> applies to GDAL 1.10 or above, and if people are using older versions some
> things might not apply.
>
>>
>> -Jukka-
>>
>> ___
>> 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 mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Using/citing GDAL documentation

[Eli Adam]

On Fri, Oct 18, 2013 at 6:13 PM, Jonathan Greenberg  wrote:
> GDALers:
>
> I'm working with a colleague on a new set of R wrappers for GDAL, and
> we are at the point where we are starting to document the functions.
> Our R interface is designed to be VERY close to the GDAL command line
> utilities (we use the same parameter names, for instance), so I was
> wondering if it would be ok to use almost word-for-word the GDAL
> documentation of each of the parameters in our package's man files
> (this would save us an inordinate amount of time paraphrasing the docs
> for all of those functions).  If this is ok, how should I cite the
> documentation properly?

I can't answer about reuse of the documentation, but citation is
probably covered here,
http://trac.osgeo.org/gdal/wiki/FAQGeneral#HowdoIciteGDAL

Hopefully someone else will more directly answer your questions (my
uninformed opinion is that reuse is probably fine).

Best Regards, Eli

>
> Cheers!  Incidentally, the package is up on R-forge:
> https://r-forge.r-project.org/projects/gdalutils/
>
> --j
>
> --
> Jonathan A. Greenberg, PhD
> Assistant Professor
> Global Environmental Analysis and Remote Sensing (GEARS) Laboratory
> Department of Geography and Geographic Information Science
> University of Illinois at Urbana-Champaign
> 259 Computing Applications Building, MC-150
> 605 East Springfield Avenue
> Champaign, IL  61820-6371
> Phone: 217-300-1924
> http://www.geog.illinois.edu/~jgrn/
> AIM: jgrn307, MSN: jgrn...@hotmail.com, Gchat: jgrn307, Skype: jgrn3007
> ___
> 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

Re: [gdal-dev] problem with gdal_translate jp2 file from the usgs (linux)

[Eli Adam]

Kasper,

On Thu, Apr 24, 2014 at 2:32 PM, Even Rouault
 wrote:
> Le jeudi 24 avril 2014 23:29:03, Kasper van Wijk a écrit :
>> thank you, Even, for the fast reply. I am a beginner at GDAL and installed
>> the gdal suite with "standard" apt-get and yum, respectively. Can you point
>> me to a place where I can read how to compile GDAL against one of the other
>> JPEG2000 libraries, as you say?

Compiling is a great option and might be the best.  You might also
want to check which drivers are in Ubuntu GIS and Enterprise Linux GIS
which might be easier than compiling.  They are often more recent and
with more features than the standard repos.

https://wiki.ubuntu.com/UbuntuGIS
http://wiki.osgeo.org/wiki/Enterprise_Linux_GIS

Best regards, Eli

>
> You will find various resources at http://trac.osgeo.org/gdal/wiki/BuildHints
>
> Most interesting links for your use case :
> * http://trac.osgeo.org/gdal/wiki/DownloadSource
> * http://trac.osgeo.org/gdal/wiki/BuildingOnUnix
> * http://trac.osgeo.org/gdal/wiki/ECW : if you want to compile against ECW SDK
> * http://gdal.org/frmt_jp2openjpeg.html : if you want to compile against
> OpenJPEG v2
>
>>
>> Thanks again,
>> Kasper
>>
>> On 25 April 2014 09:25, Even Rouault  wrote:
>> > Le jeudi 24 avril 2014 23:17:29, Kasper van Wijk a écrit :
>> > > dear all,
>> > >
>> > > I am downloading jp2 data from the usgs national map. To plot this in
>> > > cartopy, I need to transform to something else, such as geotiff.
>> > > However, using gdal_translate I get a warning copied below, and the
>> > > output is a grainy bw version of the image. I have checked my results
>> > > under linux
>> >
>> > both
>> >
>> > > fedora core 20 and ubuntu 12.04 versions with GDAL 1.7.3, released
>> > > 2010/11/10
>> > >
>> > > gdal_translate m_3810623_ne_13_1_20110921_20111031.jp2 test.tiff -of
>> >
>> > GTiff
>> >
>> > > warning: not enough tile data (2 bytes)
>> >
>> > Apparently your GDAL build uses libjasper as the jpeg2000 library. Jasper
>> > doesn't work very well unfortunately with some real world images.
>> > You might want to compile GDAL against one of the other JPEG2000
>> > libraries that are supported : see http://gdal.org/formats_list.html
>> >
>> > --
>> > Geospatial professional services
>> > http://even.rouault.free.fr/services.html
>
> --
> 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 mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] What happens by default when writing RGBA into jpeg?

[Eli Adam]

On Tue, Jun 10, 2014 at 6:28 AM, Even Rouault
 wrote:
>
>> Thanks, that makes sense. However, the result is somehow surprising and I
>> guess that in most cases unusable for the user. I wonder if it would be good
>> to print something like "WARNING. Encountered 4 source bands, assuming CMYC
>> color space". Behaviour is not very easy to understand by reading the driver
>> page http://www.gdal.org/frmt_jpeg.html
>>
>> When I try to look at the situation as a QGIS user sees it, it feels like
>> there is a bug somewhere but I can't say exactly where. However, I do not
>> believe that any average QGIS user can have success with converting their
>> RGBA tiffs into jpeg format even it is possible by editing gdal_translate
>> command manually.
>
> Agreed that the current behaviour is confusing. A check could be done on the
> color interpretation of the source bands to check if it is C,M,Y,K when a 4 
> band
> dataset is provided. If not, then output the warning (and possibly error out 
> if
> -strict is specified)

Some GDAL warning also give helpful hints.  Could this warning suggest
something like, RGBA files can be converted to JPEG by adding "-b 1 -b
2 -b 3"?

Eli

> ___
> 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

[gdal-dev] Mosaic to vrt format with gdalwarp

[Eli Adam]

Hi all,
 I'm having some trouble using gdalwarp to mosaic ArcInfo Binary Grid files 
to vrt.

Here is what I want to do and works in .tif.  I mosaic the three grids be... to 
test2.tif:
gdalwarp -t_srs "EPSG:2913" -s_srs "EPSG:2994" -srcnodata "0 0 0" -dstnodata "0 
0 0" -of GTIFF be44123g8b be44123g8c be44123g8a test2.tif
Creating output file that is 11039P x 15191L.
Processing input file be44123g8b.
0...10...20...30...40...50...60...70...80...90...100 - done.
Processing input file be44123g8c.
0...10...20...30...40...50...60...70...80...90...100 - done.
Processing input file be44123g8a.
0...10...20...30...40...50...60...70...80...90...100 - done.
test2.tif looks fine with gdalinfo and in OpenEV.


That works how I want.  However, I have many more than 3 grids and can't create 
an output file that large.  So I use vrt which has been very useful to me in 
the past:
gdalwarp -t_srs "EPSG:2913" -s_srs "EPSG:2994" -srcnodata "0 0 0" -dstnodata "0 
0 0" -of VRT be44123g8b be44123g8c be44123g8a test2.vrt
Creating output file that is 11039P x 15191L.
Processing input file be44123g8b.
test2.vrt looks fine with gdalinfo but not in OpenEv.  Also, when I look in the 
.vrt file itself, I only see one reference to the 1 grid and not to the other 2 
grids:
 be44123g8b

I also notice that when processing to tif each of the 3 grids are listed.  When 
processing to .vrt only 1 grid is listed.

I read up on vrt here, http://www.gdal.org/gdal_vrttut.html to try and manually 
create/edit a vrt file but my preliminary tries weren't successful.  

Let me know if you need any additional information on this or have any ideas.

Thanks, Eli


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

Re: [gdal-dev] Mosaic to vrt format with gdalwarp

[Eli Adam]

Frank and John,

Thanks for the suggestions.  I did take the advice to use gdalbuildvrt and then 
warp that:

gdalbuildvrt gdalbuildvrt.vrt be44123g8a be44123g8b be44123g8c be44123h7 
be44123h8a be44123h8b be44124g1 be44124h1 be45123a7 be45123a8 be45124a1

gdalwarp -t_srs "EPSG:2913" -s_srs "EPSG:2994" -of VRT gdalbuildvrt.vrt 
gdalbuildvrt2994.vrt

I forgot to mention this in the first email, but the step I was wanting to do 
next was to tile it with gdal_translate (although on different tiles than the 
original tiles): 
gdal_translate -projwin 7288440 446648 7306569 429923 gdalbuildvrt2994.vrt 
NewTile.tif
etc...

So the performance hit is well worth it for letting it run slowly through vrt 
once.  This does exactly what I want and having to add the gdalbuildvrt step is 
not much additional effort.  The only thing that it didn't do that I wanted was 
-srcnodata and -dstnodata, however, it looks like that will be available in 
1.7, right around the corner.

I also opened a ticket on this in case someone else looks for it.
http://trac.osgeo.org/gdal/ticket/3328

Thanks, Eli



>>> "John C. Tull"  1/15/2010 9:30 PM >>>
On Jan 15, 2010, at 8:29 PM, Frank Warmerdam wrote:

> Eli Adam wrote:
>> Hi all, I'm having some trouble using gdalwarp to mosaic ArcInfo Binary Grid
>> files to vrt.
>> Here is what I want to do and works in .tif.  I mosaic the three grids be...
>> to test2.tif: gdalwarp -t_srs "EPSG:2913" -s_srs "EPSG:2994" -srcnodata "0 0
>> 0" -dstnodata "0 0 0" -of GTIFF be44123g8b be44123g8c be44123g8a test2.tif 
>> Creating output file that is 11039P x 15191L. Processing input file
>> be44123g8b. 0...10...20...30...40...50...60...70...80...90...100 - done. 
>> Processing input file be44123g8c. 
>> 0...10...20...30...40...50...60...70...80...90...100 - done. Processing
>> input file be44123g8a. 0...10...20...30...40...50...60...70...80...90...100
>> - done. test2.tif looks fine with gdalinfo and in OpenEV.
>> That works how I want.  However, I have many more than 3 grids and can't
>> create an output file that large.  So I use vrt which has been very useful
>> to me in the past: gdalwarp -t_srs "EPSG:2913" -s_srs "EPSG:2994" -srcnodata
>> "0 0 0" -dstnodata "0 0 0" -of VRT be44123g8b be44123g8c be44123g8a
>> test2.vrt Creating output file that is 11039P x 15191L. Processing input
>> file be44123g8b. test2.vrt looks fine with gdalinfo but not in OpenEv.
>> Also, when I look in the .vrt file itself, I only see one reference to the 1
>> grid and not to the other 2 grids: > relativeToVRT="1">be44123g8b
>> I also notice that when processing to tif each of the 3 grids are listed.
>> When processing to .vrt only 1 grid is listed.
>> I read up on vrt here, http://www.gdal.org/gdal_vrttut.html to try and
>> manually create/edit a vrt file but my preliminary tries weren't successful.
>> Let me know if you need any additional information on this or have any
>> ideas.
> 
> Eli,
> 
> I am afraid that gdalwarp just doesn't support producing VRTs containing 
> multiple source files. It would, I think, be reasonably challenging to
> correct  - not just a quick bug fix.  You could file a ticket on it.
> 
> You could do two steps, gdalwarp each independently to TIFF, and then
> use something like gdalbuildvrt to build a mosaic vrt.  Or if the source
> files are all in the same coordinate system, perhaps you could build a
> mosaic vrt, and then use gdalwarp to produce a corresponding warped vrt.
> 
> I will say that this is pushing the VRT mechanism fairly far and the
> efficiency of the resulting layers of vrt may not be that great.

I would simply second Frank's final comment. When using a warped vrt, your 
computer has to go through the computational requirements to do the warp every 
time you load the vrt in a GIS or spatial data viewing software. This will grow 
tiresome real quickly. I have tried this myself before and determined that 
sacrificing hard drive space was preferable to sacrificing cpu cycles 
repeatedly.

Regards,
John

___
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

[gdal-dev] Re: gdal-dev Digest, Vol 68, Issue 56

[Eli Adam]

Gary, 
  I don't know that projection or the specifics with your tfw.  This 
website might help you research the projection and get the proper parameters.  
I'm not sure if this is the projection that you are after but it is similar.
http://spatialreference.org/ref/epsg/7405/

Regards, Eli

   3. Projection for OSGB36 (Smart, Gary)

--

Message: 3
Date: Wed, 27 Jan 2010 11:20:45 -
From: "Smart, Gary" 
Subject: [gdal-dev] Projection for OSGB36
To: 
Message-ID:

Content-Type: text/plain; charset="us-ascii"

I have a series of OS map TIF files with associated tfw files.  However,
the tif files contain no information about the projection.  I understand
that these files are using OSGB36 AIRY1830

 

Can anyone tell me the precise text specification I need to be able to
set up this projection.  

 

An example tfw file is:

2.5

0

0

-2.5

215000

254000 

 

I tried to importFromWkt with the string from the gdal/data/ecw_cs.wkt
but this did not seem to work.  I don't believe that OSGB36 is one of
the WellKnownGeogCS either.

 

Gary

 

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.osgeo.org/pipermail/gdal-dev/attachments/20100127/eb373888/attachment-0001.html
 

--


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

[gdal-dev] Re: How to divide a raster layer into a set of tiles

[Eli Adam]

Gilles,
 I do a similar process (build large vrt mosaic, reproject the
mosaic vrt to another vrt, tile the reprojected mosaic vrt in new
projection to tif) although my end tiles are in tif and not compressed. 
My method is the brute force way and not elegant at all.  You may also
want to know that I have been advised
(http://news.gmane.org/gmane.comp.gis.gdal.devel) that this is very
inefficient  and pushing the VRT format.  Steps 1 and 2 are the same as
you describe.

1) create a single GDAL layer from all initial tiles with gdalbuildvrt
2) reproject this virtual raster with gdalwarp (outputs a new .vrt)
3) Tile it with gdal_translate:  gdal_translate -projwin 7288440 446648
7306569 429923 mosaicvrtprj.vrt tile1.tif

The brute force part is between 2 and 3.  Make a vector file (shp or
PostGIS) grid of the new tiles in the desired projection.  Convert the
polygon grid to points, then using SQL in a database, group by the
polygon name (which needs to be retained when converted to points) and
take the min/max of x and y.  Then use SQL to concatenate gdal_translate
commands with the correct parameters.  The end result is a table of
gdal_translate commands that will make the tiles.  Save as text and make
needed minimal modification to fire off all those commands.   Not an
elegant method at all.  It could probably be done all in bash with
gdalinfo, grep, and sed, which would at least not require a database,
even if it still is a brute force method.  

I don't know if using ecw and other formats or compression options may
prevent the reading through of vrt files.  My work has been simpler,
uncompressed tif from AI binary grids.  You may also want to make sure
that each of your vrt files has all the proper projection and other
information from steps 1 and 2.  gdalinfo ortho-dept04-2004-lam93.vrt
might help.  


Bests, Eli


   2. Re: How to divide a raster layer into a set of tiles?
  (Gilles Bassi?re)
   3. Re: Re: How to divide a raster layer into a set of tiles?
  (Gilles Bassi?re)
   4. Re: How to divide a raster layer into a set of tiles?
  (Jukka Rahkonen)

--

Message: 2
Date: Tue, 23 Mar 2010 16:01:33 +0100
From: Gilles Bassi?re 
Subject: [gdal-dev] Re: How to divide a raster layer into a set of
tiles?
To: Christian M?ller 
Cc: gdal-dev@lists.osgeo.org 
Message-ID: <4ba8d7cd.1050...@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Christian Müller wrote:
> That is a surprise.
> In all my tests I had no memory problems with gdal_retile. Sometimes
I
> had some memory problems with gdal_merge. The biggest input file for
> gdal_retile was a 80 GB Erdas image (not compressed) and it works
fine.
> I have never testet with an ECW File and my tests run on a Linux Box
or
> AIX Box.
> Perhaps the problem is in the ECW gdal driver. You can try to
transform
> your ecw file in another format using gdal_transform.
> 

That's may be caused by something wrong with the ECW driver indeed. I
will test gdal_retile again once I have a clean GDAL+ECW install.

Regards
Gilles

> 
> 
> Gilles Bassière writes:
>> Christian Müller wrote:
>>> gdal_retile.py definitely creates georeferenced tiles, I developed
this
>>> utility.
>>> I did some experiments reprojecting the single tiles while
retiling, but
>>> it simply does not work. As a consequence I canceled the
reprojecting
>>> support.
>>> The solution for your problem is:
>>> 1) Use gdal_merge to create the big image
>>> 2) reproject with gdal_warp
>>> 3) use gdal_retile to create your new tiles
>>> I did a lot of experiments to avoid creating the big picture
without
>>> success.
>>
>> I understand. In my case, gdal_retile.py eventually crashed with a
>> Python MemoryError. I assume it is unsurprising with a 7.5GB input
for a
>> single Python process.
>>>
>>> Even Rouault writes:
 Le Monday 22 March 2010 19:35:47 Gilles Bassière, vous avez écrit
:
> Hi,
> The problem with this workflow is that it creates
non-georeferenced
> tiles (I don't know if this is the intended behaviour of this
> command).

 gdal_retile.py *does* create georeferenced tiles. I've just
verified
 it. What make you think the contrary ?
 ___
 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 
>>  
>>
>> -- 
>> Gilles Bassière - Web/GIS software engineer
>> http://gbassiere.free.fr/ 
> 
> 


-- 
Gilles Bassière - Web/GIS software engineer
http://gbassiere.free.fr/ 


--

Message: 3
Date: Tue, 23 Mar 2010 16:08:58 +0100
From: Gilles Bassi?re 
Subject: Re: [gdal-dev] Re: How to divide a raster layer into a set of
tiles?
To: Jukka Rahkonen 
Cc: gdal-dev@lists.osgeo.org 
Message-ID: <4ba8d98a.2020...@gmail.com>
Con

[gdal-dev] Re: How to divide a raster layer into a set of tiles

[Eli Adam]

No good reason.  I'm more familiar with the other commands since I use
them often is the main reason. A side benefit is that I can match
existing tiles on other datasets and adopt existing tile names too.  Now
that I've read the utility pages for gdal_merge and gdal_retile I see
that would be an easier method.  I'll try that next time and report if I
have problems.  The reason I recommended it to Gilles was that the
method he was trying was not going smoothly. 

Thanks for contributing these utilities.  

Bests, Eli

>>> "Christian Müller"  3/23/2010 10:40 PM
>>>
A short question 

Why did you not use 

1) gdal_merge
2) gdal_translate
3) gdal_retile 

Btw, if there is no need for reprojection, gdal_retile alone does the
job. 

Did you have problems using these utilities ? 

Eli Adam writes: 

> Gilles,
>  I do a similar process (build large vrt mosaic, reproject the
> mosaic vrt to another vrt, tile the reprojected mosaic vrt in new
> projection to tif) although my end tiles are in tif and not
compressed. 
> My method is the brute force way and not elegant at all.  You may
also
> want to know that I have been advised
> (http://news.gmane.org/gmane.comp.gis.gdal.devel) that this is very
> inefficient  and pushing the VRT format.  Steps 1 and 2 are the same
as
> you describe. 
> 
> 1) create a single GDAL layer from all initial tiles with
gdalbuildvrt
> 2) reproject this virtual raster with gdalwarp (outputs a new .vrt)
> 3) Tile it with gdal_translate:  gdal_translate -projwin 7288440
446648
> 7306569 429923 mosaicvrtprj.vrt tile1.tif 
> 
> The brute force part is between 2 and 3.  Make a vector file (shp or
> PostGIS) grid of the new tiles in the desired projection.  Convert
the
> polygon grid to points, then using SQL in a database, group by the
> polygon name (which needs to be retained when converted to points)
and
> take the min/max of x and y.  Then use SQL to concatenate
gdal_translate
> commands with the correct parameters.  The end result is a table of
> gdal_translate commands that will make the tiles.  Save as text and
make
> needed minimal modification to fire off all those commands.   Not an
> elegant method at all.  It could probably be done all in bash with
> gdalinfo, grep, and sed, which would at least not require a
database,
> even if it still is a brute force method.   
> 
> I don't know if using ecw and other formats or compression options
may
> prevent the reading through of vrt files.  My work has been simpler,
> uncompressed tif from AI binary grids.  You may also want to make
sure
> that each of your vrt files has all the proper projection and other
> information from steps 1 and 2.  gdalinfo
ortho-dept04-2004-lam93.vrt
> might help.   
> 
> 
> Bests, Eli 
> 
> 
>2. Re: How to divide a raster layer into a set of tiles?
>   (Gilles Bassi?re)
>3. Re: Re: How to divide a raster layer into a set of tiles?
>   (Gilles Bassi?re)
>4. Re: How to divide a raster layer into a set of tiles?
>   (Jukka Rahkonen) 
> 
> -- 
> 
> Message: 2
> Date: Tue, 23 Mar 2010 16:01:33 +0100
> From: Gilles Bassi?re 
> Subject: [gdal-dev] Re: How to divide a raster layer into a set of
>   tiles?
> To: Christian M?ller 
> Cc: gdal-dev@lists.osgeo.org 
> Message-ID: <4ba8d7cd.1050...@gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1 
> 
> Christian Müller wrote:
>> That is a surprise.
>> In all my tests I had no memory problems with gdal_retile.
Sometimes
> I
>> had some memory problems with gdal_merge. The biggest input file
for
>> gdal_retile was a 80 GB Erdas image (not compressed) and it works
> fine.
>> I have never testet with an ECW File and my tests run on a Linux
Box
> or
>> AIX Box.
>> Perhaps the problem is in the ECW gdal driver. You can try to
> transform
>> your ecw file in another format using gdal_transform. 
>> 
> 
> That's may be caused by something wrong with the ECW driver indeed.
I
> will test gdal_retile again once I have a clean GDAL+ECW install. 
> 
> Regards
> Gilles 
> 
>>  
>> 
>> Gilles Bassière writes:
>>> Christian Müller wrote:
>>>> gdal_retile.py definitely creates georeferenced tiles, I
developed
> this
>>>> utility.
>>>> I did some experiments reprojecting the single tiles while
> retiling, but
>>>> it simply does not work. As a consequence I canceled the
> reprojecting
>>>> support.
>>>> The solution for your problem is:
>>>> 1) Use gdal_merge to create the big image
>>>> 2) reproject with gdal_warp
>>>> 3) use gdal_retile to create your new tiles
&

[gdal-dev] gdal_rasterize -tr and -te

[Eli Adam]

I would find aligning the pixels to 'standard grid' to be useful as well.  
Similar to the -a for g.region in GRASS.  

Thanks, Eli




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

Re: [gdal-dev] Re: gdal_rasterize -tr and -te

[Eli Adam]

The results of -tap are what I expect, pixels aligned with 0,0.  Although I 
have a separate question at the end.

Prior to the patch I ran this:
 gdal_rasterize -tr 100 100 -a Elevation -l town town.shp townrasterb.tif
and got this:
gdalinfo townrasterb.tif 
...
Origin = (7267911.066051597706974,512434.991065477312077)
Pixel Size = (100.000,-100.000)
Metadata:
  AREA_OR_POINT=Area
Image Structure Metadata:
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  ( 7267911.066,  512434.991) (124d 6'49.77"W, 45d 0'53.75"N)
Lower Left  ( 7267911.066,  290634.991) (124d 4'33.15"W, 44d24'25.68"N)
Upper Right ( 7392811.066,  512434.991) (123d37'52.26"W, 45d 1'45.22"N)
Lower Right ( 7392811.066,  290634.991) (123d35'53.84"W, 44d25'16.61"N)
Center  ( 7330361.066,  401534.991) (123d51'17.02"W, 44d43' 6.24"N)
Band 1 Block=1249x1 Type=Float64, ColorInterp=Gray

After the patch I ran this:
gdal_rasterize -tr 100 100 -tap -a Elevation -l town town.shp townrasterd.tif
and got this:
gdalinfo townrasterd.tif 
...
Origin = (7267900.000,512500.000)
Pixel Size = (100.000,-100.000)
Metadata:
  AREA_OR_POINT=Area
Image Structure Metadata:
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  ( 7267900.000,  512500.000) (124d 6'49.97"W, 45d 0'54.39"N)
Lower Left  ( 7267900.000,  290600.000) (124d 4'33.28"W, 44d24'25.33"N)
Upper Right ( 7392900.000,  512500.000) (123d37'51.05"W, 45d 1'45.90"N)
Lower Right ( 7392900.000,  290600.000) (123d35'52.60"W, 44d25'16.29"N)
Center  ( 7330400.000,  401550.000) (123d51'16.49"W, 44d43' 6.41"N)
Band 1 Block=1250x1 Type=Float64, ColorInterp=Gray

town.shp is a point layer with 12 points, 11 of those points have values in -a 
Elevation (1 is null), and in the output tif, 9 pixels have values.  The far 
south and far east points do not have corresponding pixels with values.  If 
this needs review, I can open a ticket and attach a very small example.  

I include this info in this thread since that is the case before -tap and after 
-tap I get the same thing, except the far east point has a corresponding pixel 
with -tap.  This probably doesn't have anything (much) to do with -tap.   

Thanks, Eli

>>> Hermann Peifer  10/06/10 7:43 AM >>>
On 06/10/2010 16:34, Frank Warmerdam wrote:
> Hermann Peifer wrote:
>>> $ gdal_rasterize --debug on --config GDAL_CACHEMAX 2000 -ot byte
>>> -a_nodata 0 -co compress=lzw -tr 255 255 -tap -l lu001l_luxembourg -burn
>>> 1 -where CODE=111 lu001l_luxembourg.shp out.tif
>>> OGR: OGROpen(lu001l_luxembourg.shp/0x1978ae0) succeeded as ESRI
>>> Shapefile.
>>> GDAL: QuietDelete(out.tif) invoking Delete()
>>> GDAL: GDALOpen(out.tif, this=0x19cbe00) succeeds as GTiff.
>>> GDAL: GDALDefaultOverviews::OverviewScan()
>>> GDAL: GDALClose(out.tif, this=0x19cbe00)
>>> GDAL: GDALDriver::Create(GTiff,out.tif,224,321,1,Byte,0x1979ab0)
>>> ERROR 1: Type mismatch or improper type of arguments to = operator.
> ...
>> I see: ERROR 1 can be avoided by using: -where CODE=\'5\' (CODE is
>> a string field). In any case: I rasterize via a shell script and I did
>> not get the same error when running the same script last week.
>
> Herman,
>
> Were you using GDAL 1.7 last week?

No, but an earlier version of 1.8dev (a few months old, perhaps)

Hermann

___
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

[gdal-dev] Re: Testing Geospatial PDF support

[Eli Adam]

There are more geospatial pdfs available here:
http://nationalmap.gov/ustopo/index.html - then click on 'Download Maps
(Map Store)' on the left side.  

Then you need to place a marker, then click the marker, then hit
download.

I've not worked with them very much yet.  

Bests, Eli

>>> Even Rouault  10/19/2010 11:45 AM
>>>
Brent,

I'm not sure what you find is wrong. What does gdalinfo returns ?

The PDF driver will reproject the coordinates of the GPTS array from 
geographic into UTM 35N and try to build a geotransform matrix from
that. The 
matrix may have rotating terms, so you likely need to use gdalwarp
afterwards 
to make it look "straight". However I'm not 100% sure this is the
correct way 
to interpret the the Adobe style georeferencing, but I didn't find a
better one 
up to know. So if you or someone else have any clue...

Most geospatial PDFs I've found in the wild (such as the one of
cantopo) seem 
to use the OGC Best Practice encoding.

Even

Le mardi 19 octobre 2010 20:11:13, Brent Fraser a écrit :
>   Even,
> 
> 
>I've tested a couple of Geospatial PDFs with the code that's in
GDAL
> trunk.
> 
> The Canadian topos work well (e.g.
>
ftp://ftp2.cits.rncan.gc.ca/pub/cantopo/50k_geopdf/085/b/cantopo_085b14_geo

> pdf.zip). They were produced using ESRI ArcMap 9.2.6.1500.  I get a
> properly geo-referenced GeoTiff after running gdal_translate.
> 
>   I have another PDF produced by ArcMap10.0.0.2414.   It has a main
map
> and a keymap.  The strange thing is that even though the coordinate
> system is UTM Zone 35 , it has a transformation matrix with
geographic
> coordinates given.  Here's a portion of the "dump" file:
> 
>   Item[4] : VP
>Type = array
> Item[0]:
>  Type = dictionary
>   Item[0] : Name = ÿþI (string)
>   Item[1] : Measure
>Type = dictionary
> Item[0] : Subtype = GEO (name)
> Item[1] : LPTS
>  Type = array
>   Item[0]: 0 (int)
>   Item[1]: 1 (int)
>   Item[2]: 0 (int)
>   Item[3]: 0 (int)
>   Item[4]: 1 (int)
>   Item[5]: 0 (int)
>   Item[6]: 1 (int)
>   Item[7]: 1 (int)
> Item[2] : GPTS
>  Type = array
>   Item[0]: 38.815000 (real)
>   Item[1]: 23.644900 (real)
>   Item[2]: 43.662600 (real)
>   Item[3]: 23.387000 (real)
>   Item[4]: 43.615000 (real)
>   Item[5]: 31.889000 (real)
>   Item[6]: 38.774900 (real)
>   Item[7]: 31.540700 (real)
> Item[3] : GCS
>  Type = dictionary
>   Item[0] : WKT =
>
PROJCS["WGS_1984_UTM_Zone_35N",GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPH
>
EROID["WGS_1984",6378137.0,298.257223563]],PRIMEM["Greenwich",0.0],UNIT["De
>
gree",0.0174532925199433]],PROJECTION["Transverse_Mercator"],PARAMETER["Fal
>
se_Easting",50.0],PARAMETER["False_Northing",0.0],PARAMETER["Central_Me
>
ridian",27.0],PARAMETER["Scale_Factor",0.9996],PARAMETER["Latitude_Of_Origi
> n",0.0],UNIT["Meter",1.0]] (string)
>   Item[1] : Type = PROJCS (name)
> Item[4] : Type = Measure (name)
> Item[5] : Bounds
>  Type = array
>   Item[0]: 0 (int)
>   Item[1]: 1 (int)
>   Item[2]: 0 (int)
>   Item[3]: 0 (int)
>   Item[4]: 1 (int)
>   Item[5]: 0 (int)
>   Item[6]: 1 (int)
>   Item[7]: 1 (int)
>   Item[2] : Type = Viewport (name)
>   Item[3] : BBox
>Type = array
> Item[0]: 3168 (int)
> Item[1]: 2433 (int)
> Item[2]: 3557 (int)
> Item[3]: 2127 (int)
> Item[1]:
>  Type = dictionary
>   Item[0] : Name = ÿþA (string)
>   Item[1] : Measure
>Type = dictionary
> Item[0] : Subtype = GEO (name)
> Item[1] : LPTS
>  Type = array
>   Item[0]: 0 (int)
>   Item[1]: 1 (int)
>   Item[2]: 0 (int)
>   Item[3]: 0 (int)
>   Item[4]: 1 (int)
>   Item[5]: 0 (int)
>   Item[6]: 1 (int)
>   Item[7]: 1 (int)
> Item[2] : GPTS
>  Type = array
>   Item[0]: 40.190600 (real)
>   Item[1]: 26.279300 (real)
>   Item[2]: 40.767200 (real)
>   Item[3]: 26.273100 (real)
>   Item[4]: 40.769300 (real)
>   Item[5]: 27.212000 (real)
>   Item[6]: 40.192600 (real)
>   Item[7]: 27.210200 (real)
> Item[3] : GCS
>  Type = dictionary
>   Item[0] : WKT =
>
PROJCS["WGS_1984_UTM_Zone_35N",GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPH
>
EROID["WGS_1984",6378137.0,298.257223563]],PRIMEM["Greenwich",0.0],UNIT["De
>
gree",0.0174532925199433]],PROJECTION["Transverse_Mercator"],PARAMETER["Fal
>
se_Easting",50.0],PARAMETER["False_Northing",0.0],PARAMETER["Central_Me
>
ridian",27.0],PARAMETER["Scale_Factor",0.9996],PARAMETER["Latitude_Of_Origi
> n",0.0],UNIT["Meter",1.0]] (string)
>   Item[1] : Type = PROJCS (name)
> Item[4] : Type = Measure (name)
> It

Re: [gdal-dev] PDF-->JPEG-->KML. Confused about association betweenKML bounding box and PDF's neatli

[Eli Adam]

Boris,

Did you try something like:

gdalwarp -t_srs "EPSG:4326" in.jpg out.jpg

or 

gdalwarp -t_srs 'EPSG:4326' in.jpg out.jpg


HTH, Eli

>>> Boris Dev  10/20/2010 2:28 PM >>>
thanks..I am almost there...I think I am making a simple usage typo?

gdalwarp without the option '-t_srs EPSG:4326' works OK.

But it doesnt work with the command written exactly as you have it

>
> gdalwarp -t_srs EPSG:4326 in.jpg out.jpg
>
>
After that command, I do not get anything processed (it just outputs to the
screen the usage info).

I also had no luck with trying different variations of the -t_srs option
such as

gdalwarp -t_srs "+proj=EPSG:4326" in.jpg out.jpg

I am using the most recent SVN GDAL.



>  then use gdalinfo to get the corner coordinates.
>
> Currently the entire page of the PDF is rendered into the image.   Perhaps
> we can convince Even to add an option to convert only the mapped area (or
> mask everything else?)
>
> Best Regards,
> Brent Fraser
>
>
> On 10/20/2010 8:07 AM, Boris Dev wrote:
>
> My objective is to make a KML ground overlay with a geospatial PDF map.
>
> Using GDAL's translate utility I have converted the PDF to a JPEG. The next
> step and problem for me is to write the text of the KML ground overlay,
> which requires a text of bounding box information like this:
>
> 
> 37.91904192681665
> 37.46543388598137
> 15.35832653742206
> 14.60128369746704
>
>
> -0.1556640799496235
>   
>
>
> As GDAL's output, I saw that the entire PDF with legend, title, etc and not
> just the map image was converted.
>
> As GDAL's output, I also saw 2 parts of data that seem they are useful to
> match a bounding box to the map within the jpeg, but I cant figure out the
> puzzle of how to make this work? Can I get the bounding box of the entire
> PDF image with this information below?
>
> Corner Coordinates:
> Upper Left  (  666937.758, 2024687.983)
> Lower Left  (  666991.811, 2018338.153)
> Upper Right (  674511.276, 2024754.795)
> Lower Right (  674565.328, 2018404.965)
> Center  (  670751.543, 2021546.474)
>
> POLYGON ((672676.488065659650601
> 2019417.955749646294862,672636.091432046378031
> 2024030.267778463661671,667347.405745737953112
> 2023983.612156898481771,667385.539170471020043
> 2019370.524140953086317,672676.488065659650601
> 2019417.955749646294862,672676.488065659650601
> 2019417.955749646294862,672676.488065659650601
> 2019417.955749646294862,672676.488065659650601
> 2019417.955749646294862))
>
> I realize the coordinate above need to be converted to lat/long to be a KML
> ground overlay onto Google Maps, which I think I can handle.
>
> But I am unsure if I need to extract the map image from the jpeg using the
> NEATLINE?
> How are the Corner Coordinates translated into a bounding box?
>
> Any suggestions?
>
>
> ___
> gdal-dev mailing 
> listgdal-...@lists.osgeo.orghttp://lists.osgeo.org/mailman/listinfo/gdal-dev 
>
>

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

Re: [gdal-dev] RFC 32 - gdallocationinfo utility

[Eli Adam]

Frank,

 This is a helpful new utility.  

I read the documentation and tried it out.  Using gdallocationinfo to find the 
elevation at a given lat/long location seems like a reasonable use.  It may be 
desirable to input and output an ogr layer rather than a single point.  For 
instance, what are the elevations at these points in this shapefile?  

I tried to approach that problem by putting the coordinates into a file with 
ogrinfo and then use that file as an --optfile for the x y.  That didn't work 
the way that I tried it.  Can an --optfile be used for the x y input?  

ogrinfo town.shp town | grep 'POINT' | sed 's/  POINT (//' | sed 's/)//' > 
xyinput2.txt

head xyinput2.txt 
7350538.701077490113676 371057.403368594241329
7388905.153187953867018 357147.769300847954582
7346377.449287764728069 409114.138115067325998

gdallocationinfo -s_srs "EPSG:2913" townraster.tif --optfile xyinput2.txt 
Usage: gdallocationinfo [--help-general] [-xml] [-lifonly] [-valonly]
[-b band]* [-s_srs srs_def] [-geoloc] [-wgs84]
srcfile x y

What would be the proper approach to the above hypothetical problem?  Is there 
an effective way to have an ogr input for gdallocaitoninfo?  Perhaps 
-input_file_list my_liste.txt for the x y similar to gdalbuildvrt?

It looks like -s_srs applies to the x y input.  -s_srs sometimes, i.e. 
gdalwarp, applies to the srcfile.  

Is -wgs84 equivalent to -s_srs "EPSG:4326"?

These were my initial thoughts I hope that some of them may be helpful.

Thanks for the new utility, Eli


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

Re: [gdal-dev] Naive warping question

[Eli Adam]

Brian,

 You could try gdalbuildvrt, then gdalwarp that with -of VRT, then tile it 
how you like with gdal_translate.  I think that gdal_retile.py has some options 
to do what you want as well.

 I think that the slivers are probably because the projections have 
different angles of rotations and pixels may not be exactly square in each 
projection and may not map from one to the other cleanly.  Making a mosiac 
first (even if virtual) deals with this (or at least pushes it to your edges 
where you won't notice it.

HTH, Eli

>>> Brian Hamlin  12/21/2010 12:13 PM >>>
Hi All-
   I have a series of tiffs, georef'd in 4326, which side by side cover 
 >1000 km at latitude 38
California from the coast past the borders

   I warped them all to 3310 using gdalwarp with default settings..
However, the resulting images appear to leave a sliver between them
In other words, they are *not* complete coverage of the area covered
  in the original tiffs. This is unexpected to me..

Is this expected results?
How can I be sure to get complete coverage in the resulting set of 
re-projected tiffs?

   thanks
-Brian

==
Brian Hamlin
planetwork.net
OSGeo California Chapter
(415) 717-4462 cell

___
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

Re: [gdal-dev] gdal_rasterize 1.8.0 options

[Eli Adam]

Marius,

I don't know about 1. but possibilities for 2. and 3 below.  

> Hi Everyone,
> 
> Some of the options (I didn't test all) introduced with version 1.8.0
> seem to behave strangely. Here's what I'm doing:
> 1. gdal_rasterize -burn 0 -i -l mask mask.shp sample.tif
> works fine but I get the following warning:
> Warning : the output raster dataset and the input vector layer do not
> have the same SRS.
> Results might be incorrect (no on-the-fly reprojection of input data).
> even though both inputs use the same projection, EPSG:3844.
> 
> 2. gdal_rasterize -burn 0 -i -a_srs EPSG:3844 -l mask mask.shp
> sample.tif
> fails with: '-tr xres yes' or '-ts xsize ysize' is required.
> 
> 3. gdal_rasterize -burn 0 -i -a_nodata 0 -l mask mask.shp sample.tif
> fails with: '-tr xres yes' or '-ts xsize ysize' is required.
> 
>>From http://www.gdal.org/gdal_rasterize.html it doesn't seem that -a_srs
> or -a_nodata would require -tr or -ts. Am I doing something wrong?

Does sample.tif exist?  If not, the docs say you need to use -tr or -ts, "Since 
GDAL 1.8.0, the target GDAL file can be created by gdal_rasterize. One of -tr 
or -ts option must be used in that case."  I don't know why that error would 
not also come from 1. 


Bests, Eli

> 
> -marius
> 


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

Re: [gdal-dev] Conversion from WGS84 to NAD83(EPSG:26912 - NAD83 / UTMzone 12N )

[Eli Adam]

Sumit,

 Looking at EPSG:26912 on spatial reference, 
http://spatialreference.org/ref/epsg/26912/ and your longitude coordinates 
(74-76 East, no less) makes it questionable if 26912 is an appropriate 
projection.  That projection looks valid for western Mexico, and midwestern 
US/CA.  You data looks to be roughly in Asia.

 I think that error says that it is not in a valid area of the target 
projection.  

Bests, Eli

>>> On 3/1/2011 at 2:28 PM, in message 
>>> <1299018481319-6078961.p...@n2.nabble.com>,
Delirious  wrote:
> I am trying to convert a file in WGS format to Conversion from WGS84 to
> NAD83(EPSG:26912 - NAD83 / UTM zone 12N ), 
> 
> comman line input is 
> C:\Program Files (x86)\FWTools2.4.7>gdalwarp -t_srs EPSG:26912
> G:\TestData\dem43m.tif G:\TestData\opt.tif
> ERROR 1: Too many points (441 out of 441) failed to transform,
> unable to compute output bounds.
> 
> I am giving above stated error.
> 
> gdalinfo of the input file is given below 
> 
> Size is 1201, 1201
> Coordinate System is:
> GEOGCS["WGS 84",
> DATUM["WGS_1984",
> SPHEROID["WGS 84",6378137,298.257223563,
> AUTHORITY["EPSG","7030"]],
> AUTHORITY["EPSG","6326"]],
> PRIMEM["Greenwich",0],
> UNIT["degree",0.0174532925199433],
> AUTHORITY["EPSG","4326"]]
> Origin = (74.9995834,36.0004166)
> Pixel Size = (0.0008333,-0.0008333)
> Metadata:
>   TIFFTAG_SOFTWARE=ERDAS IMAGINE
>   TIFFTAG_XRESOLUTION=1
>   TIFFTAG_YRESOLUTION=1
>   TIFFTAG_RESOLUTIONUNIT=1 (unitless)
>   AREA_OR_POINT=Area
> Image Structure Metadata:
>   INTERLEAVE=BAND
> Corner Coordinates:
> Upper Left  (  74.9995833,  36.0004167) ( 74d59'58.50"E, 36d 0'1.50"N)
> Lower Left  (  74.9995833,  34.9995833) ( 74d59'58.50"E, 34d59'58.50"N)
> Upper Right (  76.0004167,  36.0004167) ( 76d 0'1.50"E, 36d 0'1.50"N)
> Lower Right (  76.0004167,  34.9995833) ( 76d 0'1.50"E, 34d59'58.50"N)
> Center  (  75.500,  35.500) ( 75d30'0.00"E, 35d30'0.00"N)
> Band 1 Block=64x64 Type=Int16, ColorInterp=Gray
> 
> Am i doing anything wrong? 
> 
> Thanks
> Sumit Pandey
> 

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

[gdal-dev] Re: Conversion from WGS84 to NAD83(EPSG:26912 - NAD83 /UTMzone 12N )

[Eli Adam]

Sumit,

  There are a lot of NAD83 UTM projection zones.  You need to chose the 
proper one.  Without learning a fair amount about datums, projections, and the 
area where you are working, you may be best looking on wikipedia and spatial 
reference to guess a UTM zone that matches your general area.  NAD83 is the 
North American Datum of 1983, you may want a different datum for your area. A 
rough guess that may be a decent starting place might be WGS84 UTM 45N.  

  Datums, projections, etc are incredibly complex.  USGS gives an overview 
here, http://egsc.usgs.gov/isb/pubs/MapProjections/projections.html  I don't 
have any advice for any easy or quick way to select a proper datum and 
projection.  If you know someone working with similar data in the same area, 
ask them.

  You may be best leaving the data in EPSG:4326, I don't know.  

HTH, Eli

>>> On 3/1/2011 at 3:21 PM, in message 
>>> <1299021669799-6079096.p...@n2.nabble.com>,
Delirious  wrote:
> Thanks adam,
> 
> I am novice to this field. So my question might seem trivial or vague -
> "Even if the data is of asia, cant it be projected in NAD83 UTM 12N. Errors
> might be high, but it should be convertible". If i want to convert this data
> in NAD83 datum and UTM projection what should i do?
> 
> Cheers
> Sumit Pandey 

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

Re: [gdal-dev] Many files over the network

[Eli Adam]

> I apologize if this question has been posted previously, but I haven't yet
> found a convenient way to search the archives.
> Thanks,
> 
> Kyle

Kyle, 
  It took me a while to find how to do that as well.  Try nabble, 
http://osgeo-org.1803224.n2.nabble.com/GDAL-Dev-f2022644.html 

Bests, Eli

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

Re: [gdal-dev] Get pixel values from all bands

[Eli Adam]

Alexander,

Not sure if it meets you situation, but there is a command line utility 
with similar functionality, gdallocationinfo, 
http://gdal.org/gdallocationinfo.html 

HTH, Eli


>>> On 3/16/2011 at 1:21 PM, in message
<20110316222128.b943f4e3.alexander.b...@gmail.com>, Alexander Bruy
 wrote:
> Hi all
> 
> I work on raster processing application (developed with C++ and Qt).
> For reading rasters we use GDAL and it's C++ API.
> 
> For one task we need to get pixel values from all raster bands. For
> this I get all GDALRasterBands and store them in list. Then in loop
> read image row by row and store row from each band in another list.
> 
> Here is simplified code
> 
> // iterate over image row by row
> for ( int row = 0; row < ySize; ++row )
> {
>   // read one row from each band and store it in list
>   for ( int b = 0; b < bandCount; ++b )
>   {
> float *scanline;
> scanline = (float *) CPLMalloc( sizeof( float ) * xSize );
> bands[ i ]->RasterIO( GF_Read, 0, row, xSize, 1, scanline, xSize,
>   1, GDT_Float32, 0, 0 );
> rows[ i ] = scanline;
>   }
> 
>   // iterate on pixels in row
>   for (int col = 0; col < ySize; ++col)
>   {
> // get pixel value from bands
> float pixel[bandCount];
> for ( int r = 0; r < bandCount; ++r )
> {
>// get value in (row, col) from band r
>double pixel[r] = rows[ r ][ col ];
> }
> // do something with this pixel
>   }
> }
> 
> Is this correct approach? Or maybe there is another more correct way
> to do this?
> 
> Also I'm not sure where I should free memory allocated with CPLMalloc().
> After reading pixels and before reading next rows or at end when
> all rows processed?
> 
> I'm not a big C++ programmer, so any help is very appreciated
> 
> Thanks

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

[gdal-dev] ftp user and password with vsizip/vsicurl

[Eli Adam]

Is it possible to use vsizip and vsicurl on a password protected ftp site?  

Something like this command with user and password passed somehow:

ogrinfo -ro -al -so 
/vsizip/vsicurl/ftp://example.com/foldername/file.zip/example.shp 

I rather hopefully tried some switches, -user:user -password:password, which 
did not work.

Thanks for the vsi support, it is awesome!  For vsizip/gz/tar, I find this wiki 
page very useful, http://trac.osgeo.org/gdal/wiki/UserDocs/ReadInZip  I can 
find all the gdal drivers that support virtual files by following the 
directions on that page (driver marked with 'v' when running 'gdalinfo 
--formats').  I tried a similar approach for ogr (ogrinfo --formats and looked 
for 'v') without learning much.  Is there a way to determine virtual file 
support in ogr?  I found that shp is supported by successfully testing it and 
recalling an IRC mention.  

Most of what I find for vsicurl is here, 
http://trac.osgeo.org/gdal/wiki/Release/1.8.0-News  Is there somewhere else 
that I should look for documentation on vsicurl?  I gave a shot at adding 
information to the vsizip wiki page, can someone review it to make sure that I 
am not spreading false information and correct or delete it if needed?  I added 
to the vsizip page rather than making a different page since vsicurl is often 
used with vsizip.  Currently, the example commands that I put there give an 
error claiming that the .shx is corrupt.  For instance, ogrinfo -ro -al -so 
/vsicurl/http://trac.osgeo.org/gdal/browser/trunk/autotest/ogr/data/poly.shp


Any help appreciated, Eli

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

Re: [gdal-dev] ftp user and password with vsizip/vsicurl

[Eli Adam]

Even,

  I've added most of this to the wiki.  I've also corrected the
urls that were incorrect. 
http://trac.osgeo.org/gdal/wiki/UserDocs/ReadInZip#vsicurl-toreadfromHTTPorFTPfilespartialdownloading

Thanks, Eli

>>> On 4/12/2011 at 11:11 AM, in message
<201104122011.20768.even.roua...@mines-paris.org>, Even Rouault
 wrote:
> Le mardi 12 avril 2011 17:26:02, Eli Adam a écrit :
>> Is it possible to use vsizip and vsicurl on a password protected ftp
site?
>> 
>> Something like this command with user and password passed somehow:
>> 
>> ogrinfo -ro -al -so
>> /vsizip/vsicurl/ftp://example.com/foldername/file.zip/example.shp 
>> 
>> I rather hopefully tried some switches, -user:user
-password:password,
>> which did not work.
> 
> I've just tried with an FTP site and ogrinfo -ro -al -so 
>
/vsizip/vsicurl/ftp://user:passw...@example.com/foldername/file.zip/example.
> shp 
> works
> 
>> 
>> Thanks for the vsi support, it is awesome!  For vsizip/gz/tar, I
find this
>> wiki page very useful,
http://trac.osgeo.org/gdal/wiki/UserDocs/ReadInZip 
>> I can find all the gdal drivers that support virtual files by
following
>> the directions on that page (driver marked with 'v' when running
'gdalinfo
>> --formats').  I tried a similar approach for ogr (ogrinfo --formats
and
>> looked for 'v') without learning much.  Is there a way to determine
>> virtual file support in ogr?  I found that shp is supported by
>> successfully testing it and recalling an IRC mention.
> 
> No, there's no easy way of knowing if an OGR driver supports VSI
virtual 
> file 
> handlers such as vsizip, vsicurl etc...
> 
> From a quick "grep -r VSILFILE ogr/ogrsf_frmts/", I can see in
current trunk 
> (might not be the case for all drivers in GDAL 1.8.0 as a few have
been 
> converted since the release), that CSV, PGDUMP (well, this is just
write-
> only),  SVG, KML, HTF, DXF, PDS, VRT, GPX, AERONAVFAA, GTM, EDIGEO,
SHAPE, 
> OPENAIR, LIBKML, GEORSS, GPSBABEL, BNA, GEOJSON, XPLANE, GMT, GML,
SUA and 
> S57 
> use the VSI virtual file API at least partially. Caution : It doesn't
mean 
> that 
> they are all fully vetted to be compatible with it.
> 
>> 
>> Most of what I find for vsicurl is here,
>> http://trac.osgeo.org/gdal/wiki/Release/1.8.0-News  Is there
somewhere
>> else that I should look for documentation on vsicurl?  I gave a shot
at
>> adding information to the vsizip wiki page, can someone review it to
make
>> sure that I am not spreading false information and correct or delete
it if
>> needed?  I added to the vsizip page rather than making a different
page
>> since vsicurl is often used with vsizip. 
> 
> There's some info in the doc of VSIInstallCurlFileHandler() here 
> http://gdal.org/cpl__vsi_8h.html#4f791960f2d86713d16e99e9c0c36258 
> 
> You might want to add the link to it, like it is done for the other
special 
> file handlers in the page.
> 
>> Currently, the example commands
>> that I put there give an error claiming that the .shx is corrupt. 
For
>> instance, ogrinfo -ro -al -so
>>
/vsicurl/http://trac.osgeo.org/gdal/browser/trunk/autotest/ogr/data/poly.s
>> hp
> 
> This was just a bad URL. ogrinfo -ro -al -so 
> /vsicurl/http://svn.osgeo.org/gdal/trunk/autotest/ogr/data/poly.shp
works
> 
>> 
>> 
>> Any help appreciated, Eli
>> 
>> ___
>> 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

Re: [gdal-dev] Re: FileGDB OGR driver test

[Eli Adam]

Ragi,

 I tested the driver on just one FileGDB which included a date
field.  You stated, 

Known issues with build / FileGDB driver
- (driver issue) blobs and date fields are not handled at all

Here is what I did and successfully got the data.  The date field was
made a double and populated with 0, however, since it says that date
fields are not handled, it is nice that the rest of the process still
worked on the other fields and the data was exported.  

ogr2ogr ODF_Lincoln_Roads.shp West_Oregon_Roads.gdb
"ODF_Lincoln_Roads"
Warning 6: Field RDSRCDATE create as date field, though DateTime
requested.

Warning 6: Normalized/laundered field name: 'CONSTRUCTED' to
'CONSTRUCTE'
Warning 6: Normalized/laundered field name: 'Shape_Length' to
'Shape_Leng'
Warning 1: Row id: 4 col:10 has unhandled col type (11). Setting to
NULL.
ERROR 1: GDB Error: Failed to determine value for column CONST_DATE
long:-2147217395
ERROR 1: GDB Error: Failed to determine value for column CONST_DATE
long:-2147217395

Thanks for the work on this.

Eli




>>> On 4/13/2011 at 11:13 AM, in message
, Ragi Burhum
 wrote:
> Perfect. Thank you Michael.
> 
> - Ragi
> 
> 
>> Date: Tue, 12 Apr 2011 15:45:25 -0400
>> From: "Smith, Michael ERDC-CRREL-NH" 
>> Subject: Re: [gdal-dev] Re: FileGDB OGR driver test
>> To: Even Rouault ,
>>
>> Message-ID: 
>> Content-Type: text/plain;   charset="ISO-8859-1"
>>
>> I have a test v10 filegdb with points, lines, polygons (all with Z
and M
>> but
>> I think the measures aren't populated). There are also some non
geometry
>> tables and some relationship classes.
>>
>> Its available at
>>
>> http://12.189.158.78:8081/downloads/test_fgdb.gdb.zip 
>>
>> Mike
>>
>>
>> --
>> Michael Smith
>> Remote Sensing/GIS Center
>> US Army Corps of Engineers
>>
>>
>>
>> On 4/12/11 2:48 PM, "Even Rouault" 
wrote:
>>
>> > Le mardi 12 avril 2011 20:40:58, Matt Wilkie a écrit :
>> >>> ArcGIS 10 FileGDB's right ?
>> >>
>> >> If the api allows for using gdb's from different versions then
the test
>> >> suite should have different versions too. In any case I can make
v10
>> gdb's.
>> >
>> > No, the FileGDB API only reads v10 gdb's.
>> >
>> >>
>> >>> Current GDAL trunk builds against FileGDB API beta3 under Linux
32bit.
>> >>> Too bad ESRI doesn't provide any 64bit build of the FileGDB API
(yet...
>> >>> ?)
>> >>
>> >> """
>> >> We are working on a Linux 64-bit release of the File Geodatabase
API. It
>> >> will not release with the 1.0 release of the API, but as a part
of a
>> >> follow on release later this year.
>> >>
>> >> Lance Shipman
>> >> Geodatabase Product Engineer, File Geodatabase
>> >> esri
>>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Re: FileGDB OGR driver test

[Eli Adam]

I tried compiling the FileGDB OGR driver on ubuntu 8.04 and got a few
errors.  On the first step I got:

eadam@lgis0229ubuntu:/usr/local/src/gdal$ g++ -Wall -g
ogr/ogrsf_frmts/filegdb/*.c* -shared -o ogr_filegdb.so -Iport -Igcore
-Iogr -Iogr/ogrsf_frmts -Iogr/ogrsf_frmts/filegdb -L. -lgdal
-I/home/eadam/filegdb/dist/include -L/home/eadam/filegdb/dist/lib 
-I/home/eadam/filegdb/dist/src/FileGDBEngine/include/FileGDBLinux
-lFileGDBAPI
In file included from ogr/ogrsf_frmts/filegdb/ogr_fgdb.h:51,
 from ogr/ogrsf_frmts/filegdb/FGdbDatasource.cpp:29:
/home/eadam/filegdb/dist/include/Geodatabase.h:237: warning: ignoring
#pragma warning 
/home/eadam/filegdb/dist/include/Geodatabase.h:238: warning: ignoring
#pragma warning 
/home/eadam/filegdb/dist/include/Geodatabase.h:242: warning: ignoring
#pragma warning 
In file included from ogr/ogrsf_frmts/filegdb/ogr_fgdb.h:51,
 from ogr/ogrsf_frmts/filegdb/FGdbDriver.cpp:29:
/home/eadam/filegdb/dist/include/Geodatabase.h:237: warning: ignoring
#pragma warning 
/home/eadam/filegdb/dist/include/Geodatabase.h:238: warning: ignoring
#pragma warning 
/home/eadam/filegdb/dist/include/Geodatabase.h:242: warning: ignoring
#pragma warning 
In file included from ogr/ogrsf_frmts/filegdb/ogr_fgdb.h:51,
 from ogr/ogrsf_frmts/filegdb/FGdbLayer.cpp:29:
/home/eadam/filegdb/dist/include/Geodatabase.h:237: warning: ignoring
#pragma warning 
/home/eadam/filegdb/dist/include/Geodatabase.h:238: warning: ignoring
#pragma warning 
/home/eadam/filegdb/dist/include/Geodatabase.h:242: warning: ignoring
#pragma warning 
In file included from ogr/ogrsf_frmts/filegdb/ogr_fgdb.h:51,
 from ogr/ogrsf_frmts/filegdb/FGdbUtils.h:33,
 from ogr/ogrsf_frmts/filegdb/FGdbUtils.cpp:29:
/home/eadam/filegdb/dist/include/Geodatabase.h:237: warning: ignoring
#pragma warning 
/home/eadam/filegdb/dist/include/Geodatabase.h:238: warning: ignoring
#pragma warning 
/home/eadam/filegdb/dist/include/Geodatabase.h:242: warning: ignoring
#pragma warning 

Then I added to ~.bashrc:
GDAL_DRIVER_PATH=/usr/local/src/gdal
export GDAL_DRIVER_PATH

then: 
eadam@lgis0229ubuntu:/usr/local/src/gdal$ ogrinfo --formats
ERROR 1: libFileGDBAPI.so: cannot open shared object file: No such file
or directory
ERROR 1: libFileGDBAPI.so: cannot open shared object file: No such file
or directory
Supported Formats:
 -> "ESRI Shapefile" (read/write)
  -> "MapInfo File" (read/write)
  -> "UK .NTF" (readonly)
  -> "SDTS" (readonly)
  -> "TIGER" (read/write)
...
...

Any suggestions?  I've been tracking trunk of gdal for about a year,
although always in a simple fashion (no plugins etc).  I would not
necessarily catch something basic.

Best Regards, Eli


>>> On 4/12/2011 at 11:47 AM, in message
<201104122047.20004.even.roua...@mines-paris.org>, Even Rouault
 wrote:
> Le mardi 12 avril 2011 20:37:06, Smith, Michael ERDC-CRREL-NH a écrit
:
>> Even,
>> 
>> How do you configure gdal/ogr to build with the linux api?
> 
> This is a bit involved since there's no ./configure support yet, so I

> compile 
> it "at hand" as a plugin
> 
> Here's the line I use from GDAL root source directory :
> 
> g++ -Wall -g ogr/ogrsf_frmts/filegdb/*.c* -shared -o ogr_filegdb.so
-Iport -
> Igcore -Iogr -Iogr/ogrsf_frmts -Iogr/ogrsf_frmts/filegdb -L. -lgdal
-
> I/home/even/filegdb/dist/include -L/home/even/filegdb/dist/lib  -
> I/home/even/filegdb/dist/src/FileGDBEngine/include/FileGDBLinux
-lFileGDBAPI
> 
> You must change the /home/even/filegdb/ paths to where you uncompress
the 
> filegdb API
> 
> And you must define the GDAL_DRIVER_PATH environmenet variable to
point to 
> the 
> path where ogr_filegdb.so is
> 
>> 
>> I'm working on getting some example datasets together.
>> 
>> Mike
>> 
>> > Le mardi 12 avril 2011 19:08:24, Hermann Peifer a écrit :
>> >> On 04/04/2011 05:05, Ragi Burhum wrote:
>> >>> Hello list,
>> >>> 
>> >>> I am trying to test a new version of the FileGDB driver for OGR,
but I
>> >>> lack enough FileGDBs to test :)
>> >> 
>> >> Is the lack of FileGDBs still an issue? At work, we have several
>> >> hundreds of them and I could check if I can make some available.
>> > 
>> > ArcGIS 10 FileGDB's right ?
>> > 
>> > Yes "real" data would be usefull. But it would also be usefull if
you (or
>> > anyone else) could provide small and freely redistribuable
>> > samples (potentially "fake" data) with different types of
>> > geometries (1 feature for each geometry type is enough in theory),
column
>> > types (integer, single, double, string, date), etc.. so that it
can be
>> > included in the GDAL/OGR autotest suite.
>> > 
>> >>> If you have an *ArcGIS 10* FileGDB and would like to test the
FileGDB
>> >>> driver (and report back), feel free to grab a gdal-trunk binary
I made
>> >>> for Windows.
>> >> 
>> >> A related question: will there ever be a FileGDB driver for a
>> >> non-Windows OS? Is this feasible at all?
>> > 
>> > Current GDAL trunk builds against FileGDB API beta3 under Linu

[gdal-dev] gdaladdo creates very large files in 1.8 but not trunk

[Eli Adam]

This is an informational report only, there are not problems in trunk.  

Using 1.8.0 from OSGeo4W on XP, I made a mosaic of about 1200 uncompressed tifs 
totally 80G.  

gdalbuildvrt mosaic.vrt *.tif

Then gdal_translated that to a compressed tif of about 8G

gdal_translate mosaic.vrt mosaic_ycbcr_big.tif -co COMPRESS=JPEG -co 
PHOTOMETRIC=YCBCR -co TILED=YES -co BIGTIFF=YES --config GDAL_CACHEMAX 800

Last step was to add some overviews:

gdaladdo --config COMPRESS_OVERVIEW JPEG --config PHOTOMETRIC_OVERVIEW YCBCR 
--config INTERLEAVE_OVERVIEW PIXEL --config BIGTIFF_OVERVIEW YES --config 
GDAL_CACHEMAX 800 -r average -ro mosaic_ycbcr_big.tif 2 4 8 16 32 64 128

It works (at least in OpenEV it displays quickly like it is using overviews), 
except the file sizes for the overviews seem odd and too large.

The tiles are about 80G, the result of gdal_translate is 8G, the result of 
gdaladdo, mosaic_ycbcr_big.tif.ovr,  is 375G!  That was using 1.8.0.

I tested on trunk on ubuntu and XP from here, http://vbkto.dyndns.org/sdk/ 
which produce reasonable results.  The ovr is about 3G.  

A dif of gdalinfo on the .tif and .ovr are the same.

(I hope that is not the result of a typo when I initially typed the command.  I 
unfortunately don't have the shell around any more but took the above listed 
commands from some notes I took.)

I have tried making the overviews internal and external with similar results.  
I also tried making the overviews on the uncompressed files (the vrt) with the 
same results.  Then I made the overviews 1 level at a time and those results 
seemed reasonable.  

I didn't find any tickets about this in trac, but don't experience this in 
trunk so apparently it is fixed.  Just reporting in case it is useful.  

Do you want any other information?  

Thanks, Eli




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

Re: [gdal-dev] Re: FileGDB OGR driver test

[Eli Adam]

I reviewed this a little further.  I was mistaken in my first report,
the field RDSRCDATE was created as DATE (as opposed to DateTime) and
populated with null.  

I had mistakenly checked and reported on the field CONST_DATE which is
created as an Integer and populated with null.  (I don't know if the
field is populated in the fgdb.)


eadam@lgis0229ubuntu:/usr/local/src/gdal$ ogrinfo --formats
ERROR 1: libFileGDBAPI.so: cannot open shared object file: No such
file
or directory
ERROR 1: libFileGDBAPI.so: cannot open shared object file: No such
file
or directory
Supported Formats:
 -> "ESRI Shapefile" (read/write)
  -> "MapInfo File" (read/write)
  -> "UK .NTF" (readonly)
  -> "SDTS" (readonly)
  -> "TIGER" (read/write)
...
...

Any suggestions?  I've been tracking trunk of gdal for about a year,
although always in a simple fashion (no plugins etc).  I would not
necessarily catch something basic.

Based on reading this two sites,
http://stackoverflow.com/questions/480764/linux-error-while-loading-shared-libraries-cannot-open-shared-object-file-no-su
and
http://replay.waybackmachine.org/20090301081221/http://www.linux.org/docs/ldp/howto/Program-Library-HOWTO/shared-libraries.html

I fixed this by calling it this way,  
eadam@lgis0229ubuntu:~$ LD_LIBRARY_PATH=.:/home/eadam/filegdb/dist/lib
ogrinfo --formats

Now I get eadam@lgis0229ubuntu:~$
LD_LIBRARY_PATH=.:/home/eadam/filegdb/dist/lib ogr2ogr
ODF_Lincoln_Roads_v2.shp ~/Desktop/West_Oregon_Roads.gdb
"ODF_Lincoln_Roads"
Warning 6: Field RDSRCDATE create as date field, though DateTime
requested.

Warning 6: Normalized/laundered field name: 'CONSTRUCTED' to
'CONSTRUCTE'
Warning 6: Normalized/laundered field name: 'Shape_Length' to
'Shape_Leng'
ERROR 1: GDB Error: Failed to determine value for column CONST_DATE
long:-2147217395
ERROR 1: GDB Error: Failed to determine value for column CONST_DATE
long:-2147217395

RDSRCDATE has dates in it now.  So it looks like this was a DateTime
field and got successfully demoted to a date field.  

Thanks, Eli



>>> On 4/12/2011 at 11:47 AM, in message
<201104122047.20004.even.roua...@mines-paris.org>, Even Rouault
 wrote:
> Le mardi 12 avril 2011 20:37:06, Smith, Michael ERDC-CRREL-NH a
écrit
:
>> Even,
>> 
>> How do you configure gdal/ogr to build with the linux api?
> 
> This is a bit involved since there's no ./configure support yet, so
I

> compile 
> it "at hand" as a plugin
> 
> Here's the line I use from GDAL root source directory :
> 
> g++ -Wall -g ogr/ogrsf_frmts/filegdb/*.c* -shared -o ogr_filegdb.so
-Iport -
> Igcore -Iogr -Iogr/ogrsf_frmts -Iogr/ogrsf_frmts/filegdb -L. -lgdal
-
> I/home/even/filegdb/dist/include -L/home/even/filegdb/dist/lib  -
> I/home/even/filegdb/dist/src/FileGDBEngine/include/FileGDBLinux
-lFileGDBAPI
> 
> You must change the /home/even/filegdb/ paths to where you
uncompress
the 
> filegdb API
> 
> And you must define the GDAL_DRIVER_PATH environmenet variable to
point to 
> the 
> path where ogr_filegdb.so is
> 
>> 
>> I'm working on getting some example datasets together.
>> 
>> Mike
>> 
>> > Le mardi 12 avril 2011 19:08:24, Hermann Peifer a écrit :
>> >> On 04/04/2011 05:05, Ragi Burhum wrote:
>> >>> Hello list,
>> >>> 
>> >>> I am trying to test a new version of the FileGDB driver for
OGR,
but I
>> >>> lack enough FileGDBs to test :)
>> >> 
>> >> Is the lack of FileGDBs still an issue? At work, we have several
>> >> hundreds of them and I could check if I can make some available.
>> > 
>> > ArcGIS 10 FileGDB's right ?
>> > 
>> > Yes "real" data would be usefull. But it would also be usefull if
you (or
>> > anyone else) could provide small and freely redistribuable
>> > samples (potentially "fake" data) with different types of
>> > geometries (1 feature for each geometry type is enough in
theory),
column
>> > types (integer, single, double, string, date), etc.. so that it
can be
>> > included in the GDAL/OGR autotest suite.
>> > 
>> >>> If you have an *ArcGIS 10* FileGDB and would like to test the
FileGDB
>> >>> driver (and report back), feel free to grab a gdal-trunk binary
I made
>> >>> for Windows.
>> >> 
>> >> A related question: will there ever be a FileGDB driver for a
>> >> non-Windows OS? Is this feasible at all?
>> > 
>> > Current GDAL trunk builds against FileGDB API beta3 under Linux
32bit.
>> > Too bad ESRI doesn't provide any 64bit build of the FileGDB API
(yet...
>> > ?)
>> > 
>> >> Hermann
>> >> ___
>> >> 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 
> ___
> 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 
ht

Re: [gdal-dev] gdaladdo creates very large files in 1.8 but not trunk

[Eli Adam]

> I'm not aware of any recent change in the GTiff driver that could have 
> "solved" 
> the issue you've seen. This is a bit surprising.
> 
> Could you also try with the -stable builds (based on 1.8 branch) from 
> http://vbkto.dyndns.org/sdk/ to compare ?

I am trying it with, 
http://vbkto.dyndns.org/sdk/PackageList.aspx?file=release-1500-gdal-1-8-mapserver-5-6.zip
 

Although not finished, based on progress so far, it looks to be working 
properly and on track to create a 3G ovr.  That is consistent with trunk.  I'll 
provide more information when it finishes.  

Eli


> 
>> This is an informational report only, there are not problems in trunk.
>> 
>> Using 1.8.0 from OSGeo4W on XP, I made a mosaic of about 1200 uncompressed
>> tifs totally 80G.
>> 
>> gdalbuildvrt mosaic.vrt *.tif
>> 
>> Then gdal_translated that to a compressed tif of about 8G
>> 
>> gdal_translate mosaic.vrt mosaic_ycbcr_big.tif -co COMPRESS=JPEG -co
>> PHOTOMETRIC=YCBCR -co TILED=YES -co BIGTIFF=YES --config GDAL_CACHEMAX 800
>> 
>> Last step was to add some overviews:
>> 
>> gdaladdo --config COMPRESS_OVERVIEW JPEG --config PHOTOMETRIC_OVERVIEW
>> YCBCR --config INTERLEAVE_OVERVIEW PIXEL --config BIGTIFF_OVERVIEW YES
>> --config GDAL_CACHEMAX 800 -r average -ro mosaic_ycbcr_big.tif 2 4 8 16 32
>> 64 128
>> 
>> It works (at least in OpenEV it displays quickly like it is using
>> overviews), except the file sizes for the overviews seem odd and too
>> large.
>> 
>> The tiles are about 80G, the result of gdal_translate is 8G, the result of
>> gdaladdo, mosaic_ycbcr_big.tif.ovr,  is 375G!  That was using 1.8.0.
>> 
>> I tested on trunk on ubuntu and XP from here, http://vbkto.dyndns.org/sdk/ 
>> which produce reasonable results.  The ovr is about 3G.
>> 
>> A dif of gdalinfo on the .tif and .ovr are the same.
>> 
>> (I hope that is not the result of a typo when I initially typed the
>> command.  I unfortunately don't have the shell around any more but took
>> the above listed commands from some notes I took.)
>> 
>> I have tried making the overviews internal and external with similar
>> results.  I also tried making the overviews on the uncompressed files (the
>> vrt) with the same results.  Then I made the overviews 1 level at a time
>> and those results seemed reasonable.
>> 
>> I didn't find any tickets about this in trac, but don't experience this in
>> trunk so apparently it is fixed.  Just reporting in case it is useful.
>> 
>> Do you want any other information?
>> 
>> Thanks, Eli
>> 
>> 
>> 
>> 
>> ___
>> 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

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

Re: [gdal-dev] gdaladdo creates very large files in 1.8 but not trunk

[Eli Adam]

>>  I'm not aware of any recent change in the GTiff driver that could have 
>> "solved" 
>> the issue you've seen. This is a bit surprising.
>> 
>> Could you also try with the -stable builds (based on 1.8 branch) from 
>> http://vbkto.dyndns.org/sdk/ to compare ?
> 
> I am trying it with, 
> http://vbkto.dyndns.org/sdk/PackageList.aspx?file=release-1500-gdal-1-8-mapserver-5-
>  
> 6.zip 
> 
> Although not finished, based on progress so far, it looks to be working 
> properly and on track to create a 3G ovr.  That is consistent with trunk.  
> I'll provide more information when it finishes.  

Yes, this produced the expected results.  Here is some information on that, 
(comments of creation included too)

E:\Orthos>dir mosaic_ycbcr_big*
04/06/2011  11:24 AM 7,780,934,363 mosaic_ycbcr_big.tif
04/11/2011  08:43 PM 3,262,697,247 mosaic_ycbcr_big.tif.ovr (created from 
svn a few days ago on ubuntu)
04/06/2011  11:24 AM 7,780,934,363 mosaic_ycbcr_big_1_8.tif 
04/14/2011  09:47 PM 3,260,246,941 mosaic_ycbcr_big_1_8.tif.ovr (created 
from 
http://vbkto.dyndns.org/sdk/PackageList.aspx?file=release-1500-gdal-1-8-mapserver-5-6.zip
 downloaded today or yesterday)
04/06/2011  11:24 AM 7,780,934,363 mosaic_ycbcr_big_addo_v2.tif
04/07/2011  03:55 AM   385,580,179,214 mosaic_ycbcr_big_addo_v2.tif.ovr 
(Created from OSGEO4W 1.8.0)
04/06/2011  11:24 AM 7,780,934,363 mosaic_ycbcr_big_win.tif
04/12/2011  08:17 PM 3,260,246,941 mosaic_ycbcr_big_win.tif.ovr (created 
from a trunk version download from Tamas's site from a few days ago)

gdalinfo for mosaic_ycbcr_big.tif and mosaic_ycbcr_big_addo_v2.tif produces 
identical results (diff'ed).  Here is one for reference.
Driver: GTiff/GeoTIFF
Files: mosaic_ycbcr_big_addo_v2.tif
   mosaic_ycbcr_big_addo_v2.tif.ovr
Size is 141400, 280500
Coordinate System is:
PROJCS["NAD83(HARN) / Oregon North (ft)",
GEOGCS["NAD83(HARN)",
DATUM["NAD83_High_Accuracy_Regional_Network",
SPHEROID["GRS 1980",6378137,298.2572221010002,
AUTHORITY["EPSG","7019"]],
AUTHORITY["EPSG","6152"]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433],
AUTHORITY["EPSG","4152"]],
PROJECTION["Lambert_Conformal_Conic_2SP"],
PARAMETER["standard_parallel_1",46],
PARAMETER["standard_parallel_2",44.34],
PARAMETER["latitude_of_origin",43.66],
PARAMETER["central_meridian",-120.5],
PARAMETER["false_easting",8202099.738],
PARAMETER["false_northing",0],
UNIT["foot",0.3048,
AUTHORITY["EPSG","9002"]],
AUTHORITY["EPSG","2913"]]
Origin = (7255000.00046718680,522299.9997485)
Pixel Size = (1.018,-1.018)
Metadata:
  AREA_OR_POINT=Area
Image Structure Metadata:
  SOURCE_COLOR_SPACE=YCbCr
  COMPRESSION=YCbCr JPEG
  INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left  ( 7255000.000,  522300.000) (124d 9'55.56"W, 45d 2'25.33"N)
Lower Left  ( 7255000.000,  241800.000) (124d 7' 0.72"W, 44d16'18.24"N)
Upper Right ( 7396400.000,  522300.000) (123d37' 7.62"W, 45d 3'23.93"N)
Lower Right ( 7396400.000,  241800.000) (123d34'38.80"W, 44d17'16.07"N)
Center  ( 7325700.000,  382050.000) (123d52'10.27"W, 44d39'52.08"N)
Band 1 Block=256x256 Type=Byte, ColorInterp=Red
  Overviews: 70700x140250, 35350x70125, 17675x35063, 8838x17532, 4419x8766, 2210
x4383, 1105x2192
Band 2 Block=256x256 Type=Byte, ColorInterp=Green
  Overviews: 70700x140250, 35350x70125, 17675x35063, 8838x17532, 4419x8766, 2210
x4383, 1105x2192
Band 3 Block=256x256 Type=Byte, ColorInterp=Blue
  Overviews: 70700x140250, 35350x70125, 17675x35063, 8838x17532, 4419x8766, 2210
x4383, 1105x2192


gdalinfo for mosaic_ycbcr_big.tif.ovr and mosaic_ycbcr_big_addo_v2.tif.ovr 
produces identical results.  Here for reference too.

Driver: GTiff/GeoTIFF
Files: mosaic_ycbcr_big_addo_v2.tif.ovr
Size is 70700, 140250
Coordinate System is `'
Image Structure Metadata:
  SOURCE_COLOR_SPACE=YCbCr
  COMPRESSION=YCbCr JPEG
  INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left  (0.0,0.0)
Lower Left  (0.0,140250.0)
Upper Right (70700.0,0.0)
Lower Right (70700.0,140250.0)
Center  (35350.0,70125.0)
Band 1 Block=128x128 Type=Byte, ColorInterp=Red
  Overviews: 35350x70125, 17675x35063, 8838x17532, 4419x8766, 2210x4383, 1105x21
92
Band 2 Block=128x128 Type=Byte, ColorInterp=Green
  Overviews: 35350x70125, 17675x35063, 8838x17532, 4419x8766, 2210x4383, 1105x21
92
Band 3 Block=128x128 Type=Byte, ColorInterp=Blue
  Overviews: 35350x70125, 17675x35063, 8838x17532, 4419x8766, 2210x4383, 1105x21
92

I can run more tests, although for results you will have to wait since it takes 
a long time to run these.  Wait, this is easier, it is reproducible with 
OSGEO4W 1.8.0 and 
http://svn.osgeo.org/gdal/trunk/autotest/warp/data/test3658.tif  (I don't know 
what this tif is designed to test, so hopefully it isn't causing problems.)

C:\Documents and Settings\eadam\Desktop>gdaladdo -ro test3658.tif 2
0...10

Re: [gdal-dev] validate/clean geometry with OGR?

[Eli Adam]

Since you are going to PostGIS anyway cleaning in PostGIS is possible.  

Here is the 2.0 PostGIS doc, 
http://postgis.refractions.net/documentation/manual-svn/ST_MakeValid.html

I think that this PostGIS 2.0 function grows out of an old contrib.  I've used 
the contrib with great success in the past.  Here are a few links on that, 
http://linfiniti.com/2010/07/cleaning-geometries-inside-postgis/
http://trac.osgeo.org/postgis/wiki/UsersWikiCleanPolygons

Eli

>>> On 4/27/2011 at 7:55 AM, in message <4db82e4a.1010...@swoodbridge.com>, 
>>> Stephen
Woodbridge  wrote:
> On 4/27/2011 10:36 AM, Elijah Robison wrote:
>> Hey devs, is anyone aware of an OGR approach to validate/clean
>> geometries, for instance, as they are being converted from SHP to
>> PostGRESql?
>> It's not uncommon to have a handful of invalid geometries (usually
>> self-intersecting polygons) in a parcel dataset, and it's impractical to
>> correct them manually. In most situations I use the "Clean Geometries"
>> function in ArcGIS, which does fix the problem. However this one
>> functionality is my main reason to retain Arc in my primary tool chain.
>>
>> I've never found a scripting approach by trolling the search engines so
>> I thought I'd ask here.
> 
> This would be an interesting tool and you might want to check the 
> postgis list as I think there have been some tools posted there to clean 
> check tables in the database.
> 
> Since I use the shp2pgsql data loader, my standard check and clean is:
> 
> update mytable set the_geom=buffer(the_geom, 0.0) where not 
> isvalid(the_geom);
> 
> -- at this point anything that is not valid probably need to be looked
> -- at or needs something like a dump the polygon as line segments and
> -- then st_build_area() on the line segments.
> 
> select count(*) from mytable where not isvalid(the_geom);
> select gid from mytable where not isvalid(the_geom);
> 
> But this is all postgis related and not GEOS related, but you might be 
> able to do the same thing directly in GEOS if you know what strategies 
> work in postgis.
> 
> -Steve W
> ___
> 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

Re: [gdal-dev] gdalinfo: corner coords in other projection

[Eli Adam]

Jon,

   gdaltransform does some of this.  It looks to do 4 corners you would 
need to do it four times or list the coordinate pairs on four lines and get 
four lines of output back.  There might be a clever way to take the output of 
gdalinfo as input into gdaltransform saving you some typing and potential 
transposing.  More here  http://gdal.org/gdaltransform.html

HTH, Eli

>>> On 5/24/2011 at 9:15 AM, in message
,
"Lefman, Jonathan ERDC-TEC-VA"  wrote:
> Hi all,
> 
> Is there an executable utility that takes the corner coordinates from a 
> gtiff
> and translates them into another projection system?  For example, I have a
> gtiff in UTM and I want to translate the coordinates of the bounding box (or
> corners) into WGS84.  Or is there a way to do this non-programmatically using
> a combination of executable utilities?
> 
> Thanks,
> 
> Jon
> 
> 
> --
> 
> Jonathan Lefman, PhD
> Geospatial Research and Engineering Division / Army Geospatial Center
> Engineer
> Research and Development Center U.S. Army Corps of Engineers
> jonathan.lef...@usace.army.mil 
> 703-428-8039
> 
> 
> ___
> 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

Re: [gdal-dev] ogr2ogr custom coordiante system

[Eli Adam]

Brian,
 
  What is the command that you tried?  If you can construct the proper 
proj4 format, it should work for ogr.  Exactly matching the string in PostGIS 
may not work and you may get a new number like 32,000 for a new SRID that was 
added in PostGIS.  This slightly older thread suggests one method to overcome 
this, 
http://osgeo-org.1803224.n2.nabble.com/specifiying-the-correct-SRID-when-sending-polygons-to-PostGIS-td2026555.html
 although I have not tried that myself.

 If you have the WKT or other format, you can get the PostGIS insert string 
or proj4 format through spatialreference.org, http://spatialreference.org/

HTH, Eli


>>> On 6/14/2011 at 7:33 AM, in message
,
Brian Fischer  wrote:
> Hi Everyone,
> I was wondering if there are any help files or guides on how to define a 
> custom coordinate system to use with the ogr2ogr.exe utility.  I am trying to 
> use it to load a shapefile into a PostGIS database.  The shapefile is in a 
> custom Minnesota County coordinate system.  When I try to define the -a_srs I 
> get an error message that says SRID is unrecognized.  I'm assume this is 
> because both OGR and PostGIS does not have the custom SRID defined.  I've 
> also tried -1 as the SRID but the utility doesn't like that either.
> 
> How would I define the custom projection so both OGR2OGR utility and PostGIS 
> recognize it?
> 
> Regards,
> Brian
> 
> Brian Fischer, CFM  GIS Manager
> Houston Engineering, Inc.
> 6901 East Fish Lake Road, Suite 140
> Maple Grove, MN 55369
> Phone: Direct: 763-493-6664 / W: 763.493.4522 / M: 763.229.2734
> Email:  bfisc...@houstoneng.com
> Website: www.houstoneng.com

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

Re: [gdal-dev] changing data type of a shapefile

[Eli Adam]

Ahmet,

 You can also change geometry type, it is also an option with
ogr2ogr [2], -nlt.  I've only used -nlt to promote to multi-geometry.  

Eli

>>> On 6/15/2011 at 7:27 AM, in message
, Chaitanya kumar
CH
 wrote:
> Ahmet,
> 
> You can use OGR SQL [1] to typecast fields and other stuff. You can
use
> ogr2ogr [2] with the -sql option and supply the sql statement.
> 
> [1]: http://trac.osgeo.org/gdal/wiki/rfc21_ogrsqlcast 
> [2]: http://www.gdal.org/ogr2ogr.html 
> 
> 2011/6/15 ahmet temiz 
> 
>> hello
>>
>> how can I change data type of a shapefile by ogr2ogr ?
>>
>> regards
>>
>> --
>> Ahmet Temiz
>> Jeoloji Müh.
>> Afet ve Acil Durum Yönetimi Başkanlığı
>> Planlama ve Zarar Azaltma Dairesi Başkanlığı
>> Bilgi ve CBS grubu
>> Eskişehir Yolu 10. km.
>> Lodumlu / Ankara
>> Tel : 0 312 2872680 / 1535
>> 
>>
>> Ahmet Temiz
>> Geological Eng.
>> Information Systems - GIS Group
>> Disaster and Emergency Management
>> of Presidency
>> ___
>> gdal-dev mailing list
>> gdal-dev@lists.osgeo.org 
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev 
>>
> 
> 
> 
> -- 
> Best regards,
> Chaitanya kumar CH.
> /tʃaɪθənjə/ /kʊmɑr/
> +91-9494447584
> 17.2416N 80.1426E
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Unwanted partial transparency when clipping

[Eli Adam]

Michael,

>>> On 7/6/2011 at 5:35 PM, in message <4e14ff42.50...@cironline.org>, Michael
Corey  wrote:
> Sure, I've uploaded samples here.
> 
> http://www.mikejcorey.com/spatial/diablo-box-sample.tif 
> http://www.mikejcorey.com/spatial/diablo-cutout-sample.tif 

I don't notice the semi-transparency in these scaled down images.  Perhaps it 
is the way your viewer reads the mask?

> 
> These are the same as the images created by the process I described (but 
> scaled down).
> 
> To your point about specifying size in the first step -- will that make 
> the process run faster, or does it do the scaling down after it builds 
> the full-resolution image?
> 
> Also, I notice that my filesize always gets significantly bigger when I 
> do the cutout step, which seems counter-intuitive to me since in theory 
> shouldn't there be less information present once the cutout is done?

-cutline does not 'discard' any data.  The extent of the data remains the same 
unless you reset those extents.  You can do that with -crop_to_cutline.  Here 
are some details from the gdalwarp page, http://gdal.org/gdalwarp.html :

-crop_to_cutline:
(GDAL >= 1.8.0) Crop the extent of the target dataset to the extent of the 
cutline. 

Polygon cutlines may be used as a mask to restrict the area of the destination 
file that may be updated, including blending. If the OGR layer containing the 
cutline features has no explicit SRS, the cutline features must be in the 
georeferenced units of the destination file. When outputing to a not yet 
existing target dataset, its extent will be the one of the original raster 
unless -te or -crop_to_cutline are specified.

Best Regards, Eli

> 
> Thanks for your help!
> 
> Michael Corey
> 
> 
> On 7/6/11 5:01 PM, Chaitanya kumar CH wrote:
>> Michael,
>>
>> Can you provide screenshots of 
>> diablo-combined-center-utm10-70pct-box.tif and 
>> diablo-combined-center-utm10-70pct-cutout.tif for comparison?
>>
>> By the way, you can perform the actions of the two gdal_translate 
>> commands in the first step with the gdal_merge.py script itself unless 
>> you want to use a specific resampling algorithm.
>>
>> On Thu, Jul 7, 2011 at 4:28 AM, Michael Corey > > wrote:
>>
>> Hi all:
>>
>> I'm using a shapefile as a clipping mask to cut out the shoreline
>> from some DOQ files that I have merged together. But when I do the
>> clipping step, I end up with unwanted semitransparency in the
>> non-clipped areas.
>>
>> I'm pretty sure the problem is only with my gdalwarp step at the end.
>>
>> Here's my process:
>>
>> gdal_merge.py -init "255" -o diablo-combined-center-utm10.tif file
>> file file file
>>
>> gdal_translate -outsize 70% 70% diablo-combined-center-utm10.tif
>> diablo-combined-center-utm10-70pct.tif
>>
>> ogrinfo -al ./diablo_canyon_detail_clipper.shp
>> //Extent: (, ) - (, )
>>
>> gdal_translate -projwin    
>> diablo-combined-center-utm10-70pct.tif
>> diablo-combined-center-utm10-70pct-box.tif
>>
>> gdalwarp -co COMPRESS=DEFLATE -cutline
>> ./diablo_canyon_detail_clipper.shp
>> diablo-combined-center-utm10-70pct-box.tif
>> diablo-combined-center-utm10-70pct-cutout.tif
>>
>> Can anyone help?
>>
>> Thanks!
>>
>> -- 
>> Michael Corey
>>
>> ___
>> gdal-dev mailing list
>> gdal-dev@lists.osgeo.org 
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev 
>>
>>
>>
>>
>> -- 
>> Best regards,
>> Chaitanya kumar CH.
>> /t?a???nj?/ /k?m?r/
>> +91-9494447584
>> 17.2416N 80.1426E

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

Re: [gdal-dev] gdalwarp over tiles in Plate carée

[Eli Adam]

> Greetings
> I'm using gdalwarp to reproject a few tiles from platecarré to UTM
WGS84
> (for a specific zone). Originally they are tiles so they don't have
any
> "blank" space between them but when I reproject to UTM I get a few
areas in
> the borders of the image. What can I do to still have a perfect
match
> between tiles?
> Thanks
> Kat

Kat, 

 I think that gdal_retile.py does what you want.  You can also
mosaic them first either with gdalwarp or (if they are large files)
gdalbuildvrt and then reproject that one mosaic.  More details here:
http://gdal.org/gdal_retile.htmlhttp://gdal.org/gdalbuildvrt.html



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

Re: [gdal-dev] gdalwarp over tiles in Plate carée

[Eli Adam]

>>  Greetings
>> I'm using gdalwarp to reproject a few tiles from platecarré to UTM
> WGS84
>> (for a specific zone). Originally they are tiles so they don't have
> any
>> "blank" space between them but when I reproject to UTM I get a few
> areas in
>> the borders of the image. What can I do to still have a perfect
> match
>> between tiles?
>> Thanks
>> Kat
> 
> Kat, 
> 
>  I think that gdal_retile.py does what you want.  You can also
> mosaic them first either with gdalwarp or (if they are large files)
> gdalbuildvrt and then reproject that one mosaic.  More details here:
> http://gdal.org/gdal_retile.htmlhttp://gdal.org/gdalbuildvrt.html


I think that I gave incomplete/incorrect information.  To reproject I
think that you will need to do use gdalwarp.  gdal_merge.py is also
another way to mosaic.

Regards, Eli

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

Re: [gdal-dev] gdalwarp over tiles in Plate carée

[Eli Adam]

Kat,

The only practical way I know to avoid these slivers of
misalignment due to projections having slightly different rotations is
to mosaic first.  I've been able to do that with even extremely large
files with the help the virtual file format (VRT) of GDAL.  If you have
tiles in one projection and want to end with a mosaic in a different
projection, mosaicing first is probably going to be easier and better. 
However, if you need to reproject the tiles first and then mosaic you
can do that.  

The way I've done that in the past is a lot of work of
reprojecting, then trimming/masking the edges that look bad, then
sometimes making a small mosaic of original tiles for the overlap areas,
reprojecting and trimming that and so on.  It is extremely laborsome and
involves lots of hand entry of coordinates.  Only do that if there is
really no better way.  

If you can't mosaic first, hopefully someone will suggest a better
method (perhaps better management of nodata values?) that is less work
than what I used to do before gdalbuildvrt.

Best Regards, Eli

> No in my case i want to reproject them first and only then to create
a
> mosaic. (maybe I was not clear on this)

> Hello Eli
> I'm using gdalwarp but I'm getting that "blank" area in the bottom of
my
> image. When I try to mosaic (or visualize) with other tile (also
reprojected
> with gdal) I get this area that was not suppose to have. Any idea how
to
> avoid this?
> Thanks
> Kat
> 
> 2011/7/8 Eli Adam 
> 
>> >>  Greetings
>> >> I'm using gdalwarp to reproject a few tiles from platecarré to
UTM
>> > WGS84
>> >> (for a specific zone). Originally they are tiles so they don't
have
>> > any
>> >> "blank" space between them but when I reproject to UTM I get a
few
>> > areas in
>> >> the borders of the image. What can I do to still have a perfect
>> > match
>> >> between tiles?
>> >> Thanks
>> >> Kat
>> >
>> > Kat,
>> >
>> >  I think that gdal_retile.py does what you want.  You can
also
>> > mosaic them first either with gdalwarp or (if they are large
files)
>> > gdalbuildvrt and then reproject that one mosaic.  More details
here:
>> > http://gdal.org/gdal_retile.html   
http://gdal.org/gdalbuildvrt.html 
>>
>>
>> I think that I gave incomplete/incorrect information.  To reproject
I
>> think that you will need to do use gdalwarp.  gdal_merge.py is also
>> another way to mosaic.
>>
>> Regards, Eli
>>
>>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] CreateCopy() works great on some NITF, not on others

[Eli Adam]

Derek,

>> This seems to work good for one NITF, but for another I am getting some 
>> problems. It seems like the one with the problems  gets a copy created, but 
>> the images themselves are just all black.

This could depend on your viewer, there is one thread about something similar 
when using ArcGIS as the viewer, 
http://lists.osgeo.org/pipermail/gdal-dev/2010-October/026444.html

The -hist (or -mm or -stats) gdalinfo switches can be helpful to determine what 
is in your raster.  This also avoids how different viewers may view the file 
(although how viewers view the file may be your next problem).  

gdalinfo -mm (or -stats or -hist)

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

Re: [gdal-dev] gdal_rasterize output off by one pixel/cell

[Eli Adam]

Matt,

 You may want to look at this ticket and see if it is the same thing. If 
so, you can add yourself to the cc list and you will get emails when there are 
updates to the ticket.  You can also add any additional relevant information to 
the ticket.

http://trac.osgeo.org/gdal/ticket/3774 

Regards, Eli



>>> On 8/20/2011 at 11:06 AM, in message
, "Burton-Kelly, Matthew"
 wrote:
> Hello,
> 
> I'm attempting to create a raster from a shapefile of point data, with grid 
> cells 1 degree square.  Although the area I have defined matches up with the 
> origin coordinates I want, and the grid cells match up with a vector 1-degree 
> grid I produced in QGIS, the squares supposedly containing the point data are 
> shifted, it looks like down and to the right.  Has anyone encountered this 
> issue before?
> 
> Here is the command I used:
> gdal_rasterize -a  -ts 360 180 -te -180 -90 180 90 -l  layer name 
> in source file>  
> 
> I have uploaded a screenshot of the output I am describing here: 
> http://www.flickr.com/photos/matthewbk/6059112633 
> 
> Thanks for any insight,
> Matt
> 
> 
> 
> 
> -
> 
> Matthew Burton-Kelly, M.S.
> 
> Graduate Student
> 
> Department of Geology and Geological Engineering
> 
> University of North Dakota
> 
> Mobile: (802) 922-3696
> 
> matthew.burton.ke...@my.und.edu
> 
> matthew.burtonke...@gmail.com
> 
> http://www.protichnoctem.com 
> 
> http://und.academia.edu/MatthewBurtonKelly 
> 
> 
> 
> "About thirty years ago there was much talk that geologists ought only to 
> observe and not theorize; and I well remember someone saying that at this 
> rate a man might as well go into a gravelpit and count the pebbles and 
> describe the colors.  How odd it is that anyone should not see that all 
> observation must be for or against some view if it is to be of any service!"
> 
> -Charles Darwin, in an 1861 letter to Henry Fawcett.

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

Re: [gdal-dev] Re: gdal_rasterize output off by one pixel/cell

[Eli Adam]

Even,
 
   This works for me and the test case included with the initial report.  

Thank you very much, Eli

>>> Even Rouault  08/28/11 5:25 AM >>>
> 
I've applied a fix in trunk in http://trac.osgeo.org/gdal/changeset/22998 . 
Please test and confirm if it works for you.

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

Re: [gdal-dev] gdal/ogr version (was NotImplementedError: Wrong number...)

[Eli Adam]

Ole,

> Is there a way of telling which one I am using (both when running
> commandline org2org and when importing the ogr module in python)?

ogr2ogr --version will work on the command line for at least the major version 
number.  I'm not sure about in python.

HTH, Eli

> 
> Cheers and thanks
> Ole


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

Re: [gdal-dev] PostgreSQL problems

[Eli Adam]

David,

 It probably is a configuration or simple error, however, you've
not given much detail to let other people try to guess what it might
be.  Kyle asked for the output of your command.  Also, the exact
command (copied from terminal) may help too.  I looked at the OGR
PosrgreSQL/PostGIS format page and copied this:

PG:"dbname='databasename' host='addr' port='5432' user='x' password='y'"

Could you try

ogrinfo PG:"dbname='mydb' host='localhost' port='5432' user='x' password='y'"

from the host machine?

What do you get?

PostgreSQL requires very complex quoting if you have any CAPs, do you
have any caps in the db name, table, name, fieldname, etc?  With lack
of information, I'm making random guesses that may not be relevant.
I'm sure that if you provide detailed information, someone
knowledgeable will quickly help you (or at least that is what I often
observe on this list).

Bests, Eli

On Thu, Oct 13, 2011 at 5:10 PM, David J. Bakeman  wrote:
> Mateusz Łoskot wrote:
>>
>> On 13 October 2011 23:47, David J. Bakeman  wrote:
>>
>>>
>>> I'm on Fedora core 14 with gdal 1.7.3.
>>>
>>> I setup postgre and created a spatial enabled database with a table that
>>> includes geometry.  I can connect using psql mydb.  However when I try
>>> ogrinfo -ro PG:dbname=mydb it fails saying no driver found.
>>>
>>
>> ogrinfo --formats | grep -i post
>>
>
> -> "PostgreSQL" (read/write)
>
> I really think it's some configuration thing but I don't know what it is?
>>
>> and see if your GDAL/OGR installation has built-in PostgreSQL support.
>>
>> Best regards,
>>
>
> ___
> 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

Re: [gdal-dev] ogrinfo and PGeo Driver for .mdb file, on Ubuntu

[Eli Adam]

Chris,

 There is also another route that may work for PGeo,
http://www.gdal.org/ogr/drv_mdb.html  I recently built that on Ubuntu but
have not used it yet.  It looks like you are close on the other route
though.

HTH, Eli

On Mon, Oct 24, 2011 at 5:35 AM, Chris Green wrote:

> Hi List
>
> ** **
>
> I’m hoping someone can help me make ogr work under Linux with the PGeo
> driver, so I can read an ESRI Personal Database .mdb file into Mapserver. I
> can see from old posts that the basic problem is that MDBTools is a bit
> ‘flaky’ and needs a DSN based connection rather than connecting direct to
> the .mdb data.
>
> ** **
>
> I have been trying to follow the instructions in
> http://www.gdal.org/ogr/drv_pgeo.html . Having installed unixODBC and
> MDBTools, I configured the odbcinst.ini and odbc.ini files as suggested and
> it seems that I have partial success because when I define my datasource in
> odbc.ini like so:
>
> ** **
>
> [my_pgeo]
>
> Description = Sample PGeo Database
>
> Driver  = Microsoft Access Driver (*.mdb)
>
> Database= /var/www/vhosts/mydomain.com/httpdocs/data/test.mdb
>
> ** **
>
> then the command ogrinfo  PGeo:my_pgeo results in the following:
>
> ** **
>
> INFO: Open of ‘PGeo:my_pgeo’ using driver ‘PGeo’ successful. 
>
> Error: syntax error at line:2 col:0
>
> ** **
>
> I can’t figure out what or where this syntax error can be. I feel that I am
> quite close to success but don’t know how to move forward from here. Can
> anyone point me in the right direction please?
>
> ** **
>
> ** **
>
> Chris 
>
> ** **
>
> ** **
>
> ** **
>
> ___
> 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

Re: [gdal-dev] ogrinfo and PGeo Driver for .mdb file, on Ubuntu

[Eli Adam]

Chris,

GDAL 1.9 is trunk so I built from source.  You need to first install
subversion, a compiler and other things to compile software.  Once you have
the proper environment, then for the basic GDAL build (which would not
include mdb of any sort) it is not too difficult and there are directions on
the wiki, http://trac.osgeo.org/gdal/wiki/BuildingOnUnix

Adding in more formats and drivers is more difficult.  Usually, there are
details on the format page, http://gdal.org/ogr/drv_mdb.html and/or the
build hints section of the wiki, http://trac.osgeo.org/gdal/wiki/BuildHints

For the way I did it for the Access mdb driver, I had to make a file
/etc/ld.so.sonf.d/libjvm.conf which just has the path pointing to libjvm.so
I did this based on the file not found errors I got after compiling and
running ogrinfo on the first attempt.  I don't fully understand what is the
proper way to address issues like this and there may be better ways.  I
first learned about it using the FileGDB driver.  Here is that thread,
http://osgeo-org.1803224.n2.nabble.com/gdal-dev-FileGDB-OGR-driver-test-td6237191.html
Even's suggestion about adding to LD_LIBRARY_PATH and these two links are
mostly what helped me figure it out.

http://stackoverflow.com/questions/480764/linux-error-while-loading-shared-libraries-cannot-open-shared-object-file-no-su
and
http://replay.waybackmachine.org/20090301081221/http://www.linux.org/docs/ldp/howto/Program-Library-HOWTO/shared-libraries.html

HTH, Eli


On Tue, Oct 25, 2011 at 12:20 AM, Chris Green wrote:

> Hi Eli
>
> ** **
>
> Thanks for your suggestion. Despite pulling most of my hair out I still
> can’t get past the syntax error thrown by the PGeo driver, so I would
> certainly be interested to follow the alternative approach. However  I see
> in the drv_mdb documentation that GDAL/OGR >=1.9.0 is required, yet I can’t
> find anything for Ubuntu later than 1.8 (from UbuntuGIS unstable).  Do you
> have 1.9 on your Ubuntu, if so could you tell me where I can find it?
>
> ** **
>
> ** **
>
> Chris
>
>  
>
> ** **
>
> *From:* Eli Adam [mailto:ea...@co.lincoln.or.us]
> *Sent:* 24 October 2011 19:32
> *To:* Chris Green
> *Cc:* gdal-dev@lists.osgeo.org
> *Subject:* Re: [gdal-dev] ogrinfo and PGeo Driver for .mdb file, on Ubuntu
> 
>
> ** **
>
> Chris,
>
>  There is also another route that may work for PGeo,
> http://www.gdal.org/ogr/drv_mdb.html  I recently built that on Ubuntu but
> have not used it yet.  It looks like you are close on the other route
> though.
>
> HTH, Eli
>
> On Mon, Oct 24, 2011 at 5:35 AM, Chris Green 
> wrote:
>
> Hi List
>
>  
>
> I’m hoping someone can help me make ogr work under Linux with the PGeo
> driver, so I can read an ESRI Personal Database .mdb file into Mapserver. I
> can see from old posts that the basic problem is that MDBTools is a bit
> ‘flaky’ and needs a DSN based connection rather than connecting direct to
> the .mdb data.
>
>  
>
> I have been trying to follow the instructions in
> http://www.gdal.org/ogr/drv_pgeo.html . Having installed unixODBC and
> MDBTools, I configured the odbcinst.ini and odbc.ini files as suggested and
> it seems that I have partial success because when I define my datasource in
> odbc.ini like so:
>
>  
>
> [my_pgeo]
>
> Description = Sample PGeo Database
>
> Driver  = Microsoft Access Driver (*.mdb)
>
> Database= /var/www/vhosts/mydomain.com/httpdocs/data/test.mdb
>
>  
>
> then the command ogrinfo  PGeo:my_pgeo results in the following:
>
>  
>
> INFO: Open of ‘PGeo:my_pgeo’ using driver ‘PGeo’ successful. 
>
> Error: syntax error at line:2 col:0
>
>  
>
> I can’t figure out what or where this syntax error can be. I feel that I am
> quite close to success but don’t know how to move forward from here. Can
> anyone point me in the right direction please?
>
>  
>
>  
>
> Chris 
>
>  
>
>  
>
>  
>
>
> ___
> 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

[gdal-dev] access attribute (non-spatial) data in .mdb with PGeo Driver

[Eli Adam]

Hi all,

On Windows, I'm trying to access non-spatial tables in an .mdb file.
With --debug on I see that the absence of a 'GDB_GeomColumns' table is
the problem.

>ogrinfo --debug on Surveys.mdb
PGeo: EstablishSession(DRIVER=Microsoft Access Driver (*.mdb);DBQ=Surveys.mdb)
ODBC: SQLDriverConnect(DRIVER=Microsoft Access Driver (*.mdb);DBQ=Surveys.mdb)
PGEO: SELECT on GDB_GeomColumns fails, perhaps not a personal geodatabase?
[Microsoft][ODBC Microsoft Access Driver] The Microsoft Jet database engine cann
ot find the input table or query 'GDB_GeomColumns'.  Make sure it exists and tha
t its name is spelled correctly.
ODBC: SQLDisconnect()

I noticed this fairly recent commit, which seems to indicate that this
is the desired behavior, http://trac.osgeo.org/gdal/changeset/21550

I was able to access the non-spatial attributes by making a
'GDB_GeomColumns' table and falsely populating it (and ignoring the
missing 'GDB_SpatialRefs' table errors).

TableName   FieldName   ShapeType   ExtentLeft  ExtentBottom
ExtentRight ExtentTop   IdxOriginX  IdxOriginY  IdxGridSize 
SRIDHasZHasM
Survey  Shape   4   7255394.59721669241841.239197335
7396378.9177745 524650.4612300040   0   141508.958339791
1   0   0

>ogrinfo -so Surveys.mdb Survey
ERROR 1: 'SELECT srtext FROM GDB_SpatialRefs WHERE srid = 1' failed.
[Microsoft][ODBC Microsoft Access Driver] The Microsoft Jet database engine cann
ot find the input table or query 'GDB_SpatialRefs'.  Make sure it exists and tha
t its name is spelled correctly.
INFO: Open of `Surveys.mdb'
  using driver `PGeo' successful.

Layer name: Survey
Geometry: Unknown (any)
Feature Count: 20790
Extent: (7255394.597217, 241841.239197) - (7396378.917775, 524650.461230)
Layer SRS WKT:
(unknown)
Geometry Column = Shape
DocumentName: String (25.0)
SurveyDate: DateTime (19.0)
...


If the general case requires a 'GDB_GeomColumns' table, could no
'GDB_GeomColumns' table be made a driver config option?

I noticed that the new Access MDB driver,
http://gdal.org/ogr/drv_mdb.html , does not require a GDB_GeomColumns
table (tested on ubuntu 10.04 and gdal trunk).


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

Re: [gdal-dev] access attribute (non-spatial) data in .mdb with PGeo Driver

[Eli Adam]

Thanks Even.

> I'm confused because if you get to the point of having the trace " PGEO:
> SELECT on GDB_GeomColumns fails, perhaps not a personal geodatabase?" it means
> that you got after the test of r21550 (which should have discared this mdb as
> having no GDB_GeomColumns table), so I highly suspect you are not using trunk
> version for this test.

Correct.  I'm using an old OSGeo4W 1.8dev.  Yes, I should have noticed
that I was not using the results of that r21550.

>
> r21550 only enforces what existed before : the PGeo driver can only handle
> PGeo MDBs. The new test was introduced specifically to avoid the PGeo driver 
> to
> try opening a MDB that should be recognized by the Geomedia driver (new in
> trunk).

I confirmed that I don't get that trace with the gisinternals
release-1600-gdal-mapserver (from about 2 weeks ago).  I also checked
with this before writing the list, but just checked that trunk also
didn't open the file.  I didn't redo the --debug on portion.

>
> Why not using the generic ODBC driver for that use case ?

This is apparently what I should have been doing.  I'll try that now.

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

Re: [gdal-dev] Re: OGR2OGR and SQL Spatial

[Eli Adam]

Fred,

  You may need to use -f with the Code from this page:
http://gdal.org/ogr/ogr_formats.html  (-f MSSQLSpatial)

HTH, Eli

On Wed, Nov 16, 2011 at 4:21 PM, Fred Jones  wrote:
> Hi Sig,
>
> This is the command I have so far. When I execute it, I just get the help
> returned, no error and no table created:
>
> ogr2ogr -overwrite -s_srs EPSG:32100 -t_srs EPSG:4326 -f
> "MSSQL:server=ELMER;database=CENSUS_2010;trusted_connection=yes"
> "MSSQL:server=ELMER;database=HT_2010_10;tables=temp_sublocs_btc;trusted_connection=yes"
>
> What am I doing wrong?
>
> Thx,
> - Hide quoted text -
>
> On Wed, Nov 16, 2011 at 1:32 AM, Luca Sigfrido Percich 
> wrote:
>
> Hi Fred,
>
> first of all check if there is an EPSG entry for your coordinate system.
> Googlin' "Montana State Plane NAD 27 EPSG" pointed me to the several
> pages, among with, for example:
>
> http://www.eye4software.com/resources/stateplane/
>
> which states:
>
> 2500 NAD83 / Montana 32100
>
> So the EPSG code you're looking for is seems to be 32100. Assuming you
> want to reproject to Lon/Lat WGS84 (EPSG 4326), you need to use the
> -s_srs and -t_srs parameters:
>
> ogr2ogr -s_srs EPSG:32100 -t_srs EPSG:4326 -f "MSSQL:..." input.csv
>
> ___
> 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

Re: [gdal-dev] A gdal-users mailing list?

[Eli Adam]

Hermann,

Just a note that this topic has been on the list before,
http://lists.osgeo.org/pipermail/gdal-dev/2010-March/023779.html

Bests, Eli

>
> Hi all,
>
> Could it (perhaps) make sense to have a gdal-users mailing list, in analogy
> to grass-users, qgis-users, etc. ?
>
> I assume that, according to some logic, GDAL/OGR is considered to be a
> library from/for developers, not a GIS application for end-users. On the
> other hand, there are quite some documented utilities around [1], utilised
> by gdal-users like me. Actually, if I compare [1] with [2], I see that my
> "make install" installs many more utilities/scripts than mentioned on the
> GDAL Utilities page.
>
> Users might have (..hmm..) simple questions that real developers might
> consider to be (..hmm..) not so interesting. gdal-users could be a list
> where experienced users reply to newcomers, with the side-effect of reducing
> some traffic on gdal-dev.
>
> Hermann
>
> [1] http://www.gdal.org/gdal_utilities.html
>
> [2] $ make install
>
>     1  libtool: install: (...) gdalinfo
>     2  libtool: install: (...) gdal_translate
>     3  libtool: install: (...) gdaladdo
>     4  libtool: install: (...) gdalwarp
>     5  libtool: install: (...) nearblack
>     6  libtool: install: (...) gdalmanage
>     7  libtool: install: (...) gdalenhance
>     8  libtool: install: (...) gdaltransform
>     9  libtool: install: (...) gdaldem
>    10  libtool: install: (...) gdallocationinfo
>    11  libtool: install: (...) gdalsrsinfo
>    12  libtool: install: (...) gdal_contour
>    13  libtool: install: (...) gdaltindex
>    14  libtool: install: (...) gdal_rasterize
>    15  libtool: install: (...) gdal_grid
>    16  libtool: install: (...) ogrinfo
>    17  libtool: install: (...) ogr2ogr
>    18  libtool: install: (...) ogrtindex
>    19  libtool: install: (...) testepsg
>    20  libtool: install: (...) gdalbuildvrt
>
>    21  libtool: install: (...) scripts/epsg_tr.py
>    22  libtool: install: (...) scripts/esri2wkt.py
>    23  libtool: install: (...) scripts/gcps2vec.py
>    24  libtool: install: (...) scripts/gcps2wld.py
>    25  libtool: install: (...) scripts/gdal2tiles.py
>    26  libtool: install: (...) scripts/gdal2xyz.py
>    27  libtool: install: (...) scripts/gdal_calc.py
>    28  libtool: install: (...) scripts/gdalchksum.py
>    29  libtool: install: (...) scripts/gdal_fillnodata.py
>    30  libtool: install: (...) scripts/gdalident.py
>    31  libtool: install: (...) scripts/gdalimport.py
>    32  libtool: install: (...) scripts/gdal_merge.py
>    33  libtool: install: (...) scripts/gdal_polygonize.py
>    34  libtool: install: (...) scripts/gdal_proximity.py
>    35  libtool: install: (...) scripts/gdal_retile.py
>    36  libtool: install: (...) scripts/gdal_sieve.py
>    37  libtool: install: (...) scripts/mkgraticule.py
>    38  libtool: install: (...) scripts/pct2rgb.py
>    39  libtool: install: (...) scripts/rgb2pct.py
> ___
> 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

Re: [gdal-dev] .ovr files and Lanczos

[Eli Adam]

Are .ovr files just tifs with a different file extension?

If so, could you use, gdalwarp -tr # # -r lanczos output.ovr?

Eli

On Mon, Nov 28, 2011 at 10:57 PM, Chaitanya kumar CH
 wrote:
> Robb,
>
> Note that the quality is effected by the levels you choose.
> Can you provide a small part of the image where the overview is garbled the
> most.
>
>
> On Tue, Nov 29, 2011 at 12:00 PM, Robb Wright  wrote:
>>
>> Thanks Chaitanya.  Unfortunately gdaladdo doesn't support the Lanczos
>> resampling type.  Lanczos creates - by far - the best looking downsampled
>> images for my type of rasters.  What I'm looking for is a way to create
>> pyramid layers/.ovr files using the Lanczos resampling method.
>>
>> Robb
>>
>>
>> On 11/29/2011 12:58 AM, Chaitanya kumar CH wrote:
>>
>> Robb,
>>
>> If you are using gdal version 1.6 or later, you can use the -ro option[1].
>> It opens the tiff file in read-only mode and creates external overview.
>>
>> [1]: http://www.gdal.org/gdaladdo.html
>>
>> On Mon, Nov 28, 2011 at 11:53 PM, Robb Wright 
>> wrote:
>>>
>>>
>>> I'm working with indexed color types of raster data (charts).  The data
>>> is in RGB geotiffs and I'm using gdaladdo to create pyramid layers for them.
>>>  Unfortunately, the best method for this raster type available using
>>> gdaladdo is still pretty bad - much of the linework becomes garbled when
>>> viewing the pyramids.  The best-looking method that I've been able to come
>>> up with is:
>>> gdaladdo.exe --config COMPRESS_OVERVIEW DEFLATE -r average
>>>
>>> The Lanczos algorithm method works beautifully when used with other
>>> programs - but I need to create .ovr files.  gdal_retile.py output looks
>>> great - but I can't figure out how to create .ovr files from that output.
>>>
>>> Does anybody know of the availability of the Lanczos resampling method
>>> for gdaladdo - or of another way to create .ovr files with Lanczos?
>>>
>>> Robb
>>> ___
>>> gdal-dev mailing list
>>> gdal-dev@lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>>
>>
>>
>> --
>> Best regards,
>> Chaitanya kumar CH.
>>
>> +91-9494447584
>> 17.2416N 80.1426E
>>
>>
>
>
>
> --
> Best regards,
> Chaitanya kumar CH.
>
> +91-9494447584
> 17.2416N 80.1426E
>
> ___
> 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

Re: [gdal-dev] editor that color codes mapfile syntax?

[Eli Adam]

There is also a plugin for scite (http://www.scintilla.org/SciTE.html).

This link for the MapServer plug in is dead but you can still find it
on archive.org

http://ms.gis.umn.edu:8081/ms_plone/docs/link
http://web.archive.org/web/20100913161428/http://ms.gis.umn.edu:8081/ms_plone/docs/link

You will need to edit the SciTEGlobal.properties file to enable it.
I've attached the map.properties  as well.

Bests, Eli

PS. you might notice that this is slightly out of date and thus
probably doesn't have full MapServer 6.0 syntax highlighting.



On Tue, Dec 13, 2011 at 2:03 PM, jdm  wrote:
> Thanks Michael,
>
> This is a great little utility.
>
> Cheers,
> Derek
>
>
> On 12/13/2011 2:15 PM, Smith, Michael wrote:
>>
>> http://sites.google.com/site/gianpierocampanella/files
>>
>>
>> *
>> Michael Smith
>> State GIS Manager, Maine Office of GIS, Maine OIT
>> Board Member, Maine GeoLibrary
>> Board Member, Maine GIS Users Group
>> State Rep, National States Geographic Information Council
>>
>> | MEGIS | GeoLibrary | MEGUG | NSGIC |
>>
>> State House Station 174
>> 264 Civic Center Drive
>> Augusta, ME 04333-0174
>> (207) 215-5530
>>
>> 69 o 47' 49.5"W   44 o 20' 54.5"N
>>
>>
>>
>> -Original Message-
>> From: gdal-dev-boun...@lists.osgeo.org
>> [mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of jdmorgan
>> Sent: Tuesday, December 13, 2011 2:12 PM
>> To: gdal-dev@lists.osgeo.org
>> Subject: [gdal-dev] editor that color codes mapfile syntax?
>>
>> Hello,
>> I was wondering if anyone knows of an editor that color codes mapfile
>> syntax?  I use notepad++ currently for python, but it would be great to
>> have sytax coloring for .map files.
>>
>> Thanks,
>>
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev


map.properties
Description: Binary data
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev