[gdal-dev] NTv2 geographic transformation

[jblazquez]

Hi
I'm trying to make a transformation between ud50 and etrs98 for some files
shp. This transformation must do it through the grid system (NTv2). To do
this I have the official transformation file
(http://www.ign.es/ign/layoutIn/herramientas.do). I read that 1.8 has a GDAL
driver specific to that transformation. The sample script that exists in the
install package (GDAL-1.8.0 \ swig \ python \ samples \ loslas2ntv2.py) is
valid only for transforming images.
My issue is to know how I can make this transformation vector files

I'm using python 2.7 with GDAL 1.8.

Any help or Ideas would be appreciated




--
View this message in context: 
http://osgeo-org.1803224.n2.nabble.com/NTv2-geographic-transformation-tp6557712p6557712.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

Re: [gdal-dev] Forcing the rounded of coordinates

[Sylvain MAFFREN]

Hello and thank you for that answer.

I think if it was a rounding effect that appears at display time when 
ogrinfo outputs the WKT representation, I should have the same results 
on several data but this is notthe case.


Indeed,by querying topology between the source layer and output layer 
(checking to see if the two layers overlap perfectly), I didn't have any 
results. That's means that the coordinates of output have been changed 
by ogr2ogr and that's why I think it's not a rounding effect.


It is there a chance that changes be made to add a parameter in ogr2ogr 
in order to force the rounded coordinates with a number of decimal 
defined by user in future versions of gdal / ogr? We would be willing to 
fund this improvement if necessary.


Thank you in advance for your feedback.

Le 22/06/2011 09:56, Even Rouault a écrit :

This might be just a rounding effect that appears at display time when ogrinfo
outputs the WKT representation, but not affect the output data itself. Likely
993366.058 and 993366 are 2 decimal representations for the same
binary representation. There's no generation option to control the coordinate
precision of the output in ogr2ogr. A few drivers/formats that are text-based
have a layer/dataset creation option to control it, but this is driver/format
dependant. You might want (or not!) to hack into the ugly logic of
OGRFormatDouble() in ogr/ogrutils.cpp that is the main responsible for what
you observe...



>  Hi !
>  
>  I apologize in advance for my english which I not very fluent. I have

>  some questions about the tool ogr2ogr (and also about gdalwarp and
>  gdal_translate) and the rounding of coordinates.
>  
>  
>  Let me explain:
>  
>  Some databases (particularly IGN -- France databases) have coordinates

>  rounded to the meter (BD CARTO for example) or the decimeter (BD TOPO
>  for example).
>  
>  I will explain my comment with for bases the coordinates of a point of

>  BD CARTO to support my comments :
>  
>  In an original *.shp in Lambert93 - France, a point has the following

>  coordinates (provided by ogrinfo):
>  
>  X = 993366 m Y = 6304044 m
>  
>  We import this in PostGIS with shp2pgsql, and the point has always these

>  coordinates:
>  
>  X = 993366 m Y = 6304044 m
>  
>  It's good !
>  
>  If we try to export this PostGIS layer through ogr2ogr (in *.shp, *.tab

>  or *.mif), a ogrinfo gives us the same point of the layer resulting,
>  with the following coordinates:
>  
>  X = and Y = 993366.058 6304043.999898)
>  
>  This means that ogr2ogr (identical tests performed on a raster layer

>  bounding box with reprojection (gdalwarp) or without (gdal_translate))
>  changes the number of decimal coordinates of origin, which can be
>  annoying in some cases (when we need to recover a given output with the
>  same number of decimal than in entry.
>  
>  I tried to find a setting to force ogr2ogr (or gdal and related

>  functions) to round the coordinates to a given number of decimal (as can
>  be done with CS2CS) and I have not found any answer.
>  
>  Is it possible to set the number of decimal places in output (and

>  ideally keep the same as input) ? And if so, how?
>  
>  Thank you in advance to all who have good ideas and / or directions to

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

[gdal-dev] Re: Warping an image with both a geotransform and control points

[Jan Hartmann]

Hi all,

This has come up before, but I'm still struggling for an answer. I want 
to rubbersheet an already projected image with control points, so as to 
remove small errors.On a suggestion by Frank 
(http://lists.osgeo.org/pipermail/gdal-dev/2009-February/019775.html) I 
produced a VRT file of the georeferenced image and added control points 
to shift the image 1000m to the right. (see below). However,  GDALWARP 
ignores the control points and returns the original georeferenced image. 
When I remove the georeferencing information, it does use the control 
points, but returns a raw image shifted to the right.


Is it possible to rubbersheet a georeferenced image with control points, 
or am I chasing a red herring?


Thanks,

Jan


PROJCS["Amersfoort / RD 
New",GEOGCS["Amersfoort",DATUM["Amersfoort",SPHEROID["Bessel 
1841",6377397.155,299.152812808,AUTHORITY["EPSG","7004"]],AUTHORITY["EPSG","6289"]],PRIMEM["Greenwich",0],UNIT["degree",0.0174532925199433],AUTHORITY["EPSG","4289"]],PROJECTION["Oblique_Stereographic"],PARAMETER["latitude_of_origin",52.156160],PARAMETER["central_meridian",5.387639],PARAMETER["scale_factor",0.079],PARAMETER["false_easting",155000],PARAMETER["false_northing",463000],UNIT["metre",1,AUTHORITY["EPSG","9001"]],AUTHORITY["EPSG","28992"]]
 -8.5000e+03,  1.e+03,  
0.e+00,  2.8750e+05,  
0.e+00,  1.e+03



BAND


Y="0.E+00" />
Y="0.E+00" />
Y="2.E+03" />
Y="1.E+03" />




Gray

test.tif
1
BlockXSize="310" BlockYSize="3" />






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

Re: [gdal-dev] Forcing the rounded of coordinates

[Even Rouault]

Selon Sylvain MAFFREN :

> Hello and thank you for that answer.
>
> I think if it was a rounding effect that appears at display time when
> ogrinfo outputs the WKT representation, I should have the same results
> on several data but this is notthe case.
>
> Indeed,by querying topology between the source layer and output layer
> (checking to see if the two layers overlap perfectly), I didn't have any
> results. That's means that the coordinates of output have been changed
> by ogr2ogr and that's why I think it's not a rounding effect.

Actually, it might not be a rounding effect at display time. Paul Ramsey
identified that when inserting data into a Postgis instance, we used the WKT
representation, thus introducing rounding problem effects. You might want to
test latest trunk and see if it improves the situation for you. The relevant
ticket is http://trac.osgeo.org/gdal/ticket/4138

So now, there should be no precision loss when moving data from/to
shapefile/postgresql with ogr2ogr.

But if I've well understood your scenario, your issue seems to be more when you
pull data from Postgis.

>
> It is there a chance that changes be made to add a parameter in ogr2ogr
> in order to force the rounded coordinates with a number of decimal
> defined by user in future versions of gdal / ogr? We would be willing to
> fund this improvement if necessary.
>
> Thank you in advance for your feedback.

There is no general solution for avoiding precision loss. For sure, not a
ogr2ogr level, because ogr2ogr doesn't change coordinate precision (no text
conversion, just setting variables of type double). If there are rounding
issues, they must be tracked down at the driver level, and for each driver, it
will depend on the actual direction of the data flow (reading vs writing). A
reproducable example of ogr command lines you use with associated data would be
helpfull to understand what's going on in your case.

Now, if you want to change/force coordinate precision, I can imagine that it
*could* be done at ogr2ogr by converting the source geometry object to WKT with
a given precision and then converted back to a destination geometry object. But
the output driver (at least the text based ones) should have a way to know how
many decimals are expected.

I'd note that currently a few text based drivers (bna, geojson recently) have
specific creation options to control the precision in write mode. AFAIR, there's
also ticket in Trac for the same wish for KML.

>
> Le 22/06/2011 09:56, Even Rouault a écrit :
>
> This might be just a rounding effect that appears at display time when
> ogrinfo
> outputs the WKT representation, but not affect the output data itself. Likely
> 993366.058 and 993366 are 2 decimal representations for the same
> binary representation. There's no generation option to control the coordinate
> precision of the output in ogr2ogr. A few drivers/formats that are text-based
> have a layer/dataset creation option to control it, but this is driver/format
> dependant. You might want (or not!) to hack into the ugly logic of
> OGRFormatDouble() in ogr/ogrutils.cpp that is the main responsible for what
> you observe...
>
>
> > >  Hi !
> > >
> > >  I apologize in advance for my english which I not very fluent. I have
> > >  some questions about the tool ogr2ogr (and also about gdalwarp and
> > >  gdal_translate) and the rounding of coordinates.
> > >
> > >
> > >  Let me explain:
> > >
> > >  Some databases (particularly IGN -- France databases) have coordinates
> > >  rounded to the meter (BD CARTO for example) or the decimeter (BD TOPO
> > >  for example).
> > >
> > >  I will explain my comment with for bases the coordinates of a point of
> > >  BD CARTO to support my comments :
> > >
> > >  In an original *.shp in Lambert93 - France, a point has the following
> > >  coordinates (provided by ogrinfo):
> > >
> > >  X = 993366 m Y = 6304044 m
> > >
> > >  We import this in PostGIS with shp2pgsql, and the point has always these
> > >  coordinates:
> > >
> > >  X = 993366 m Y = 6304044 m
> > >
> > >  It's good !
> > >
> > >  If we try to export this PostGIS layer through ogr2ogr (in *.shp, *.tab
> > >  or *.mif), a ogrinfo gives us the same point of the layer resulting,
> > >  with the following coordinates:
> > >
> > >  X = and Y = 993366.058 6304043.999898)
> > >
> > >  This means that ogr2ogr (identical tests performed on a raster layer
> > >  bounding box with reprojection (gdalwarp) or without (gdal_translate))
> > >  changes the number of decimal coordinates of origin, which can be
> > >  annoying in some cases (when we need to recover a given output with the
> > >  same number of decimal than in entry.
> > >
> > >  I tried to find a setting to force ogr2ogr (or gdal and related
> > >  functions) to round the coordinates to a given number of decimal (as can
> > >  be done with CS2CS) and I have not found any answer.
> > >
> > >  Is it possible to set the number of decimal places in output (and
> > >  idea

Re: [gdal-dev] NTv2 geographic transformation

[Ralf Suhr]

Hi jblazquez,

for vector files use ogr2ogr.

Gr
Ralf


Am Donnerstag 07 Juli 2011, 11:38:56 schrieb jblazquez:
> Hi
> I'm trying to make a transformation between ud50 and etrs98 for some files
> shp. This transformation must do it through the grid system (NTv2). To do
> this I have the official transformation file
> (http://www.ign.es/ign/layoutIn/herramientas.do). I read that 1.8 has a
> GDAL driver specific to that transformation. The sample script that exists
> in the install package (GDAL-1.8.0 \ swig \ python \ samples \
> loslas2ntv2.py) is valid only for transforming images.
> My issue is to know how I can make this transformation vector files
> 
> I'm using python 2.7 with GDAL 1.8.
> 
> Any help or Ideas would be appreciated
> 
> 
> 
> 
> --
> View this message in context:
> http://osgeo-org.1803224.n2.nabble.com/NTv2-geographic-transformation-tp65
> 57712p6557712.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] Re: Warping an image with both a geotransform and control points

[Chaitanya kumar CH]

Jan,

If you are just going to shift the image, just the GeoTransform element
should be enough. You don't need the GCPs.

On Thu, Jul 7, 2011 at 3:04 PM, Jan Hartmann  wrote:

> **
> Hi all,
>
> This has come up before, but I'm still struggling for an answer. I want to
> rubbersheet an already projected image with control points, so as to remove
> small errors.On a suggestion by Frank (
> http://lists.osgeo.org/pipermail/gdal-dev/2009-February/019775.html) I
> produced a VRT file of the georeferenced image and added control points to
> shift the image 1000m to the right. (see below). However,  GDALWARP ignores
> the control points and returns the original georeferenced image. When I
> remove the georeferencing information, it does use the control points, but
> returns a raw image shifted to the right.
>
> Is it possible to rubbersheet a georeferenced image with control points, or
> am I chasing a red herring?
>
> Thanks,
>
> Jan
>
> 
>   PROJCS["Amersfoort / RD
> New",GEOGCS["Amersfoort",DATUM["Amersfoort",SPHEROID["Bessel
> 1841",6377397.155,299.152812808,AUTHORITY["EPSG","7004"]],AUTHORITY["EPSG","6289"]],PRIMEM["Greenwich",0],UNIT["degree",0.0174532925199433],AUTHORITY["EPSG","4289"]],PROJECTION["Oblique_Stereographic"],PARAMETER["latitude_of_origin",52.156160],PARAMETER["central_meridian",5.387639],PARAMETER["scale_factor",0.079],PARAMETER["false_easting",155000],PARAMETER["false_northing",463000],UNIT["metre",1,AUTHORITY["EPSG","9001"]],AUTHORITY["EPSG","28992"]]
>-8.5000e+03,  1.e+03,
> 0.e+00,  2.8750e+05,  0.e+00,
> 1.e+03
>   
>   
> BAND
>   
>   
>  Y="0.E+00" />
>  Y="0.E+00" />
>  Y="2.E+03" />
>  Y="1.E+03" />
>   
>   
> 
> Gray
> 
>   test.tif
>   1
>DataType="Float64" BlockXSize="310" BlockYSize="3" />
>   
>   
> 
>   
> 
>
> ___
> 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] NTv2 geographic transformation

[Frank Warmerdam]

On Thu, Jul 7, 2011 at 2:38 AM, jblazquez  wrote:
> Hi
> I'm trying to make a transformation between ud50 and etrs98 for some files
> shp. This transformation must do it through the grid system (NTv2). To do
> this I have the official transformation file
> (http://www.ign.es/ign/layoutIn/herramientas.do). I read that 1.8 has a GDAL
> driver specific to that transformation. The sample script that exists in the
> install package (GDAL-1.8.0 \ swig \ python \ samples \ loslas2ntv2.py) is
> valid only for transforming images.
> My issue is to know how I can make this transformation vector files

jblazquez,

The introduction of the NTv2 driver in GDAL was done so that NTv2 files
could be produced more easily from other sources.  It is not involved in
*utilizing* the NTv2 files for geometric transformations.

PROJ.4 actually applies the NTv2 transformations but it can be invoked
from ogr2ogr.

Hopefully you can do something like:

ogr2ogr \
  -s_srs WGS84
  -t_srs "+proj=latlong +ellps=WGS84 +nadgrids=./your.ntv2 +wktext"
  out.shp in.shp

The above assumes the coordinates are geographic (lat/long decimal
degrees).   The thing to keep in mind is that PROJ.4 only knows about
transforming to and from WGS84.  So you need to trick it into thinking
that one coordinate system is WGS84 and the other is something
different which the grid shift file.

Note, I'm vague on what direction the transformation is stored in within
the NTv2 file, so you may find that the example I gave moves things
the wrong way.  If so, just switch -t_srs and -s_srs around.

It would be nice to have a real world, tested, example of this in the
Trac wiki as the question does come up fairly often.

Best regards,
-- 
---+--
I set the clouds in motion - turn up   | Frank Warmerdam, warmer...@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent
___
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] Motion: Accept GDAL/OGR 1.8.1RC1 as final release

[Tamas Szekeres]

Frank,

I have found 2 issues related to the mssql spatial and the mapinfo tab
driver.

http://trac.osgeo.org/gdal/ticket/4149
http://trac.osgeo.org/gdal/ticket/4150

Committed the fix for each and it would be great to have these changes in
1.8.1

Best regards,

Tamas




2011/7/7 Frank Warmerdam 

> Folks,
>
> Motion: That we accept the GDAL/OGR 1.8.1RC1 package as the
> final GDAL/OGR 1.8.1 release.
>
> --
>
> PSC members, please vote after at least some sort of testing.
> Non-PSC members please let us know if you discover problems!
>
> --
>
> +1 Frank
>
> --
>
> ---+--
> I set the clouds in motion - turn up   | Frank Warmerdam,
> warmer...@pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush| Geospatial Programmer for Rent
> ___
> 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] Using gdalwarp with HDF files- problem reading proejction

[António Rocha]

Greetings

I have a dataset (in HDF) and I need to convert its projection. When I 
do gdalinfo I get this information:

Coordinate System is:
GEOGCS["Unknown datum based upon the Clarke 1866 ellipsoid",
   DATUM["Not specified (based on Clarke 1866 spheroid)",
   SPHEROID["Clarke 1866",6378206.4,294.9786982139006,
   AUTHORITY["EPSG","7008"]]],
   PRIMEM["Greenwich",0],
   UNIT["degree",0.0174532925199433]]
Origin = (-10.0013888,45.0013890)
Pixel Size = (0.0027778,-0.0027778)

But this is odd. I was suppose to get Plate-Carrée with geographic 
Lat/Long and Ref ellipsoid

WGS 84 Spherical Radius= Equatorial Radius=Re= 6378,14km)

Why am I no obtaining this information? Nevertheless, has this any 
impact or shall I use *-s_srs and define it do Plate Carée (EPSG:??) ?

*Thanks
Antonio


__ Information from ESET NOD32 Antivirus, version of virus signature 
database 6272 (20110707) __

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com


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

Re: [gdal-dev] Frank going to Google and it is not mentionned once on the list!

[Tamas Szekeres]

Congrats for the new job, Frank!

Best regards,

Tamas




2011/7/7 Frank Warmerdam 

> Sylvain,
>
> Consider it mentioned now!  I had my first day today (lots to take in).
>
> I discussed this on my blog at:
>
>  http://fwarmerdam.blogspot.com/2011/06/joining-google.html
>
> The short summary is that while I intend to remain active working on GDAL
> it won't be as much as before, and I won't be available for paid consulting
> on GDAL due to the nature of my US work visa.
>
> Best regards,
>
> On Wed, Jul 6, 2011 at 1:50 PM, s duclos  wrote:
> > A quick search for "frank warmerdam google" on Google return 53,200
> results
> >
> > The same search on Bing return 16,400 results
> > But then Bing tell us that "Related Search: .. Frank Sinatra, .. Frank
> Zappa, ..
> > Anna Frank"
> >
> > Some guys at Google are going to have a chuckle
> >
> > Congrat!
> >
> >
> > Sylvain.
> > ___
> > gdal-dev mailing list
> > gdal-dev@lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/gdal-dev
> >
>
>
>
> --
>
> ---+--
> I set the clouds in motion - turn up   | Frank Warmerdam,
> warmer...@pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush| Geospatial Programmer for Rent
> ___
> 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] Motion: Accept GDAL/OGR 1.8.1RC1 as final release

[Frank Warmerdam]

Tamas,

I have also discovered that I got the release date wrong by one
month in the RC1 so I will change my vote to "-1" on the RC1.  I'll
prepare an RC2 - likely tonight.

Best regards,

On Thu, Jul 7, 2011 at 7:21 AM, Tamas Szekeres  wrote:
> Frank,
>
> I have found 2 issues related to the mssql spatial and the mapinfo tab
> driver.
>
> http://trac.osgeo.org/gdal/ticket/4149
> http://trac.osgeo.org/gdal/ticket/4150
>
> Committed the fix for each and it would be great to have these changes in
> 1.8.1
>
> Best regards,
>
> Tamas
>
>
>
>
> 2011/7/7 Frank Warmerdam 
>>
>> Folks,
>>
>> Motion: That we accept the GDAL/OGR 1.8.1RC1 package as the
>> final GDAL/OGR 1.8.1 release.
>>
>> --
>>
>> PSC members, please vote after at least some sort of testing.
>> Non-PSC members please let us know if you discover problems!
>>
>> --
>>
>> +1 Frank
>>
>> --
>>
>> ---+--
>> I set the clouds in motion - turn up   | Frank Warmerdam,
>> warmer...@pobox.com
>> light and sound - activate the windows | http://pobox.com/~warmerdam
>> and watch the world go round - Rush    | Geospatial Programmer for Rent
>> ___
>> gdal-dev mailing list
>> gdal-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>



-- 
---+--
I set the clouds in motion - turn up   | Frank Warmerdam, warmer...@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Using gdalwarp with HDF files- problem reading proejction

[Joaquim Luis]

António,

I don't know what is a "WGS 84 Spherical Radius". WGS84 is an ellipsoid 
with Equatorial radius of 6378.137  km  (flattening 1/298.2572235630)


Why you are getting that info? Well, that's because it is encoded in the 
file (and apparently not the one you expected).


Joaquim


Greetings

I have a dataset (in HDF) and I need to convert its projection. When I 
do gdalinfo I get this information:

Coordinate System is:
GEOGCS["Unknown datum based upon the Clarke 1866 ellipsoid",
   DATUM["Not specified (based on Clarke 1866 spheroid)",
   SPHEROID["Clarke 1866",6378206.4,294.9786982139006,
   AUTHORITY["EPSG","7008"]]],
   PRIMEM["Greenwich",0],
   UNIT["degree",0.0174532925199433]]
Origin = (-10.0013888,45.0013890)
Pixel Size = (0.0027778,-0.0027778)

But this is odd. I was suppose to get Plate-Carrée with geographic 
Lat/Long and Ref ellipsoid

WGS 84 Spherical Radius= Equatorial Radius=Re= 6378,14km)

Why am I no obtaining this information? Nevertheless, has this any 
impact or shall I use *-s_srs and define it do Plate Carée (EPSG:??) ?

*Thanks
Antonio


______ Information from ESET NOD32 Antivirus, version of virus 
signature database 6272 (20110707) __


The message was checked by ESET NOD32 Antivirus.

http://www.eset.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] hdf5image metadata problems

[Alex Mantaut]

Hi,
   I posted a patch to solve this issue... It fecthes the metadata
from the subdaset opened (it keeps the global metadata and it adds the
subdaset metadata to it) I tested it and it is working... Please
review it to see it isn' disruptive with the rest of the driver's
logic.

http://trac.osgeo.org/gdal/ticket/4121#comment:4

Regards

2011/6/21 Alex Mantaut :
> Hi all, I updated the ticket with what was discussed with Antonio...
>
> http://trac.osgeo.org/gdal/ticket/4121#comment:3
>
> The defect is still there
>
> Regards
> Alex
>
> PS:Sorry for the delay but the weekend was a national holyday...
>
> 2011/6/18 Antonio Valentino 
>>
>> Hi Alex,
>>
>> Il 16/06/2011 17:27, Alex Mantaut ha scritto:
>> > Then, to keep consistency, the fact that hdf5imagedataset isn't
>> > consistent
>> > with the hdf5dataset is a defect, right?
>> > May I summarize the conclusions and update the ticket?
>>
>> OK
>>
>> --
>> Antonio Valentino
>> ___
>> gdal-dev mailing list
>> gdal-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
>
> --
> --
>  Alex Mantaut
> SUR Emprendimientos Tecnológicos
>
> Perú 345  Piso 5to Oficina "B" (C1067AAG)
> Ciudad de Buenos Aires, Argentina
> Tel. +54 (11) 4342-2976/84
> alexmant...@suremptec.com.ar
> www.suremptec.com
>



-- 
--
 Alex Mantaut
SUR Emprendimientos Tecnológicos

Perú 345  Piso 5to Oficina "B" (C1067AAG)
Ciudad de Buenos Aires, Argentina
Tel. +54 (11) 4342-2976/84
alexmant...@suremptec.com.ar
www.suremptec.com
___
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

[Michael Corey]

Thanks for your responses, Chaitanya and Eli. The semitransparency isn't 
really noticeable until you put the image on top of something else (in 
Photoshop or another program).


It looks like the problem is actually in my gdal_merge.py command. 
That's where the semitransparency is getting introduced.


gdal_merge.py -init "255" -o diablo-combined-utm10.tif file file file

What I'm trying to get is a merged image where no data = transparent. 
Would this be correct in that case?


gdal_merge.py -n "255" -ul_lr 380309.272908 4653610.244134 
1317796.950998 3614484.073320 -o test-combined.tif file file file


Michael Corey
Digital Innovations Editor
Center for Investigative Reporting
510.809.3178


On 7/7/11 7:13 AM, Eli Adam wrote:

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 Coreymailto:mco...@cironline.org>>  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] Creating modified copies of a file

[Cole, Derek]

Well, I am about to give up on this I think and go a different route for 
creating a NITF from this data.

I tried a small test file, and it takes about 45s to CopyCrate() an 80mb NITF. 

here is the output I got after turning on CPL_DEBUG

GDAL: GDALOpen(/home/dcole/eraser/Images/dan_data.ntf, this=0x1ad7ec70) 
succeeds as NITF.
GDAL: QuietDelete(test1.ntf) invoking Delete()
GDAL: GDALOpen(test1.ntf, this=0x1ad81180) succeeds as NITF.
GDAL: GDALDefaultOverviews::OverviewScan()
GDAL: GDALClose(test1.ntf, this=0x1ad81180)
Warning 6: NITF only supports WGS84 geographic and UTM projections.

0GDAL: Potential thrashing on band 1 of /home/dcole/eraser/Images/dan_data.ntf.
...10...20...30...40...50...60...70...80...90...100 - done.
ERROR 6: Apparently no space reserved for IGEOLO info in NITF file.
NITFWriteIGEOGLO() fails.
ERROR 6: NITF only supports WGS84 geographic and UTM projections.

GDAL: GDALDefaultOverviews::OverviewScan()
ERROR 6: NITF only supports WGS84 geographic and UTM projections.


So to try to remedy this I changed the cachemax (programmatically) anywhere 
from 40MB to 3GB trying to see if any setting had any effect. It was about the 
same no matter what. 

I tried doing a gdal_translate on this file, which only took about a second. 
Looking through the source for that, it seems like I am doing approximately the 
same thing in relation to the CreateCopy(), so I am not sure what the problem 
is. However, my viewer which uses GDAL to read the original NITF file I am 
reading in will NOT read the translated NITF file that is generated. 

Any idea why the gdal_translate might be running faster than my CreateCopy, 
even though the parameters are just about identical?

Derek

From: Even Rouault [even.roua...@mines-paris.org]
Sent: Wednesday, July 06, 2011 5:32 PM
To: gdal-dev@lists.osgeo.org
Cc: Cole, Derek
Subject: Re: [gdal-dev] Creating modified copies of a file

Le mercredi 06 juillet 2011 23:18:21, Cole, Derek a écrit :
> I have noticed that when attempting to do this, I am able to do a gdalinfo
> on the source and destination files (even if the destination file is not
> complete, it seems the header gets created, and gdalinfo recognizes teh
> file).
>
> Is it possible that this is taking so long because my destination file has
> no geocoords or projection information? It seems like createcopy is not
> replicating all of the variables in the original and I am having to
> manually set some things, such as Block size, ABPP, etc etc.

This is expected. When doing CreateCopy() the target driver has no idea what
the source driver is, so he will not recognize ABPP. As far as block sizes are
concerned, it is up to the user to decide if he wants to keep or change the
block dimension of the source dataset.

I'm a bit surprised that CreateCopy() is *that* much slower than cp, but it is
hard to know why without a hard work of profiling. It might be related to pixel
or band interleaving, etc... There might cache trashing. You could perhaps run
with CPL_DEBUG=ON and see if interesting info comes up.

> And the
> coordinates and projection information is blank in the new file. Is there
> perhaps some calculations being done to correct that issue, and thats why
> the copy is taking forever?

No, not related at all.

> I thought based on the documentation
> CreateCopy() would clone the file's raster, as well as size, type,
> projection, geotransform, etc, but all of this is not showing up in the
> partially created file at least.

You cannot reliably trust gdalinfo on a file still being written. Depending on
the driver some information might just be written at the end of the process. A
quick look at the CreateCopy() implementation of the NITF driver suggests that
this is indeed the case since the geotransform is set after the imagery.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Creating modified copies of a file

[Even Rouault]

Le jeudi 07 juillet 2011 19:52:34, Cole, Derek a écrit :
> Well, I am about to give up on this I think and go a different route for
> creating a NITF from this data.
> 
> I tried a small test file, and it takes about 45s to CopyCrate() an 80mb
> NITF.

Yes, that's very poor performance !

> 
> here is the output I got after turning on CPL_DEBUG
> 
> GDAL: GDALOpen(/home/dcole/eraser/Images/dan_data.ntf, this=0x1ad7ec70)
> succeeds as NITF. GDAL: QuietDelete(test1.ntf) invoking Delete()
> GDAL: GDALOpen(test1.ntf, this=0x1ad81180) succeeds as NITF.
> GDAL: GDALDefaultOverviews::OverviewScan()
> GDAL: GDALClose(test1.ntf, this=0x1ad81180)
> Warning 6: NITF only supports WGS84 geographic and UTM projections.
> 
> 0GDAL: Potential thrashing on band 1 of
> /home/dcole/eraser/Images/dan_data.ntf.
> ...10...20...30...40...50...60...70...80...90...100 - done.
> ERROR 6: Apparently no space reserved for IGEOLO info in NITF file.
> NITFWriteIGEOGLO() fails.
> ERROR 6: NITF only supports WGS84 geographic and UTM projections.
> 
> GDAL: GDALDefaultOverviews::OverviewScan()
> ERROR 6: NITF only supports WGS84 geographic and UTM projections.
> 

This error seems to indicate that your source dataset has an incompatible 
projection with what NITF allows (UTM/WGS84 and LongLat/WGS84). But this is 
weird because your source dataset seems to be a NITF itself... What does 
gdalinfo returns as projection for /home/dcole/eraser/Images/dan_data.ntf ?

But I don't believe it relates with performance. And I suppose you get the 
same warnings when using gdal_translate.

> 
> So to try to remedy this I changed the cachemax (programmatically) anywhere
> from 40MB to 3GB trying to see if any setting had any effect. It was about
> the same no matter what.

For a 80MB file, playing with cachemax won't give any significant speed-up.

> 
> I tried doing a gdal_translate on this file, which only took about a
> second.

That's much more reasonable. Well, then that shows it's not an issue in GDAL 
per se, but how you use it. Now, you "just" have to discover what things you 
do which are different from gdal_translate.

> Looking through the source for that, it seems like I am doing
> approximately the same thing in relation to the CreateCopy(), so I am not
> sure what the problem is. However, my viewer which uses GDAL to read the
> original NITF file I am reading in will NOT read the translated NITF file
> that is generated.

I've just reviewed the code snippet you pasted yesterday and I see that you 
use a custom progress function. Isn't there a sleep() or some slow operation 
in it ?

For debugging performance issues, I start by just running the code under a 
debugger and to break and resume execution regularly. In 90% of the cases, you 
will see easily the bottleneck because the same function comes again and 
again. Otherwise you might need more advanced tools. sysprof or kcachegrind 
under Linux might be usefull to get timing profiles.

> 
> Any idea why the gdal_translate might be running faster than my CreateCopy,
> even though the parameters are just about identical?
> 
> Derek
> 
> From: Even Rouault [even.roua...@mines-paris.org]
> Sent: Wednesday, July 06, 2011 5:32 PM
> To: gdal-dev@lists.osgeo.org
> Cc: Cole, Derek
> Subject: Re: [gdal-dev] Creating modified copies of a file
> 
> Le mercredi 06 juillet 2011 23:18:21, Cole, Derek a écrit :
> > I have noticed that when attempting to do this, I am able to do a
> > gdalinfo on the source and destination files (even if the destination
> > file is not complete, it seems the header gets created, and gdalinfo
> > recognizes teh file).
> > 
> > Is it possible that this is taking so long because my destination file
> > has no geocoords or projection information? It seems like createcopy is
> > not replicating all of the variables in the original and I am having to
> > manually set some things, such as Block size, ABPP, etc etc.
> 
> This is expected. When doing CreateCopy() the target driver has no idea
> what the source driver is, so he will not recognize ABPP. As far as block
> sizes are concerned, it is up to the user to decide if he wants to keep or
> change the block dimension of the source dataset.
> 
> I'm a bit surprised that CreateCopy() is *that* much slower than cp, but it
> is hard to know why without a hard work of profiling. It might be related
> to pixel or band interleaving, etc... There might cache trashing. You
> could perhaps run with CPL_DEBUG=ON and see if interesting info comes up.
> 
> > And the
> > coordinates and projection information is blank in the new file. Is there
> > perhaps some calculations being done to correct that issue, and thats why
> > the copy is taking forever?
> 
> No, not related at all.
> 
> > I thought based on the documentation
> > CreateCopy() would clone the file's raster, as well as size, type,
> > projection, geotransform, etc, but all of this is not showing up in the
> > partially created file at lea

RE: [gdal-dev] Creating modified copies of a file

[Cole, Derek]

Yes, the source data is a NITF. Here is the first few lines of the projection 
info  in that source NITF:
Coordinate System is:
PROJCS["unnamed",
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.257223563,
AUTHORITY["EPSG","7030"]],
TOWGS84[0,0,0,0,0,0,0],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0,
AUTHORITY["EPSG","8901"]],
UNIT["degree",0.0174532925199433,
AUTHORITY["EPSG","9108"]],
AUTHORITY["EPSG","4326"]],
PROJECTION["Transverse_Mercator"],
PARAMETER["latitude_of_origin",0],
PARAMETER["central_meridian",-75],
PARAMETER["scale_factor",0.996],
PARAMETER["false_easting",50],
PARAMETER["false_northing",0]]


I suppose I can go back through my code and change it to be exactly like 
gdal_translate, which seems to use the C bindings instead of C++.  I did end up 
changing my progress reporting function to the same one that is in 
gdal_translate as well, which had no change. I will try the debugging route 
before too much trouble, to see what I can find out. 

Thanks for the help so far. I will report back what I find.




From: Even Rouault [even.roua...@mines-paris.org]
Sent: Thursday, July 07, 2011 2:13 PM
To: gdal-dev@lists.osgeo.org
Cc: Cole, Derek
Subject: Re: [gdal-dev] Creating modified copies of a file

Le jeudi 07 juillet 2011 19:52:34, Cole, Derek a écrit :
> Well, I am about to give up on this I think and go a different route for
> creating a NITF from this data.
>
> I tried a small test file, and it takes about 45s to CopyCrate() an 80mb
> NITF.

Yes, that's very poor performance !

>
> here is the output I got after turning on CPL_DEBUG
>
> GDAL: GDALOpen(/home/dcole/eraser/Images/dan_data.ntf, this=0x1ad7ec70)
> succeeds as NITF. GDAL: QuietDelete(test1.ntf) invoking Delete()
> GDAL: GDALOpen(test1.ntf, this=0x1ad81180) succeeds as NITF.
> GDAL: GDALDefaultOverviews::OverviewScan()
> GDAL: GDALClose(test1.ntf, this=0x1ad81180)
> Warning 6: NITF only supports WGS84 geographic and UTM projections.
>
> 0GDAL: Potential thrashing on band 1 of
> /home/dcole/eraser/Images/dan_data.ntf.
> ...10...20...30...40...50...60...70...80...90...100 - done.
> ERROR 6: Apparently no space reserved for IGEOLO info in NITF file.
> NITFWriteIGEOGLO() fails.
> ERROR 6: NITF only supports WGS84 geographic and UTM projections.
>
> GDAL: GDALDefaultOverviews::OverviewScan()
> ERROR 6: NITF only supports WGS84 geographic and UTM projections.
>

This error seems to indicate that your source dataset has an incompatible
projection with what NITF allows (UTM/WGS84 and LongLat/WGS84). But this is
weird because your source dataset seems to be a NITF itself... What does
gdalinfo returns as projection for /home/dcole/eraser/Images/dan_data.ntf ?

But I don't believe it relates with performance. And I suppose you get the
same warnings when using gdal_translate.

>
> So to try to remedy this I changed the cachemax (programmatically) anywhere
> from 40MB to 3GB trying to see if any setting had any effect. It was about
> the same no matter what.

For a 80MB file, playing with cachemax won't give any significant speed-up.

>
> I tried doing a gdal_translate on this file, which only took about a
> second.

That's much more reasonable. Well, then that shows it's not an issue in GDAL
per se, but how you use it. Now, you "just" have to discover what things you
do which are different from gdal_translate.

> Looking through the source for that, it seems like I am doing
> approximately the same thing in relation to the CreateCopy(), so I am not
> sure what the problem is. However, my viewer which uses GDAL to read the
> original NITF file I am reading in will NOT read the translated NITF file
> that is generated.

I've just reviewed the code snippet you pasted yesterday and I see that you
use a custom progress function. Isn't there a sleep() or some slow operation
in it ?

For debugging performance issues, I start by just running the code under a
debugger and to break and resume execution regularly. In 90% of the cases, you
will see easily the bottleneck because the same function comes again and
again. Otherwise you might need more advanced tools. sysprof or kcachegrind
under Linux might be usefull to get timing profiles.

>
> Any idea why the gdal_translate might be running faster than my CreateCopy,
> even though the parameters are just about identical?
>
> Derek
> 
> From: Even Rouault [even.roua...@mines-paris.org]
> Sent: Wednesday, July 06, 2011 5:32 PM
> To: gdal-dev@lists.osgeo.org
> Cc: Cole, Derek
> Subject: Re: [gdal-dev] Creating modified copies of a file
>
> Le mercredi 06 juillet 2011 23:18:21, Cole, Derek a écrit :
> > I have noticed that when attempting to do this, I am able to do a
> > gdalinfo on the source and destination files (even if the destination
> > file is not complete, it se

RE: [gdal-dev] Creating modified copies of a file

[Cole, Derek]

I actually just out of curiosity tried to open the file given by this command:

gdal_translate dan_data.ntf dan_data_translate.ntf

And it turns out that dan_data_translate.ntf was actually a TIFF file that I 
could view. I had to explicitly add the option -of NITF

in which case it still did the translate very fast, but I did get warnings:

$ gdal_translate dan_data.ntf dan_data_translate.ntf -of NITF
Input file size is 8689, 7679
Warning 6: NITF only supports WGS84 geographic and UTM projections.

0...10...20...30...40...50...60...70...80...90...100 - done.
ERROR 6: Apparently no space reserved for IGEOLO info in NITF file.
NITFWriteIGEOGLO() fails.
ERROR 6: NITF only supports WGS84 geographic and UTM projections.


Which jives with what my code was giving me, and further, 
dan_data_translate.ntf is not able to be opened using my viewer (which uses 
GDAL to open the files I have been working with, of course, and does open 
dan_data.ntf) because of a segmentation fault  in the RasterIO method. I am 
able to open the gdal_translate file, and my CreateCopy() file in another ELT, 
such as ENVI.

I will also make note that the original file is exactly 72.0 MB, and the output 
file is 63.6MB, but both files say in gdalinfo they are not using compression. 
This is the same for my CreateCopy() or gdal_translate. So at least I have 
narrowed down that I am apparently getting the same end-result as 
gdal_translate, albeit way slower. Finally, the output file seems to have 
created row-blocks, instead of 1024x1024 blocks like the original. 

I will continue working to replicate gdal_translate exactly, even though now i 
am not optimistic about getting a good result.


From: gdal-dev-boun...@lists.osgeo.org [gdal-dev-boun...@lists.osgeo.org] on 
behalf of Cole, Derek [dc...@integrity-apps.com]
Sent: Thursday, July 07, 2011 2:48 PM
To: gdal-dev@lists.osgeo.org
Subject: RE: [gdal-dev] Creating modified copies of a file

Yes, the source data is a NITF. Here is the first few lines of the projection 
info  in that source NITF:
Coordinate System is:
PROJCS["unnamed",
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.257223563,
AUTHORITY["EPSG","7030"]],
TOWGS84[0,0,0,0,0,0,0],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0,
AUTHORITY["EPSG","8901"]],
UNIT["degree",0.0174532925199433,
AUTHORITY["EPSG","9108"]],
AUTHORITY["EPSG","4326"]],
PROJECTION["Transverse_Mercator"],
PARAMETER["latitude_of_origin",0],
PARAMETER["central_meridian",-75],
PARAMETER["scale_factor",0.996],
PARAMETER["false_easting",50],
PARAMETER["false_northing",0]]


I suppose I can go back through my code and change it to be exactly like 
gdal_translate, which seems to use the C bindings instead of C++.  I did end up 
changing my progress reporting function to the same one that is in 
gdal_translate as well, which had no change. I will try the debugging route 
before too much trouble, to see what I can find out.

Thanks for the help so far. I will report back what I find.




From: Even Rouault [even.roua...@mines-paris.org]
Sent: Thursday, July 07, 2011 2:13 PM
To: gdal-dev@lists.osgeo.org
Cc: Cole, Derek
Subject: Re: [gdal-dev] Creating modified copies of a file

Le jeudi 07 juillet 2011 19:52:34, Cole, Derek a écrit :
> Well, I am about to give up on this I think and go a different route for
> creating a NITF from this data.
>
> I tried a small test file, and it takes about 45s to CopyCrate() an 80mb
> NITF.

Yes, that's very poor performance !

>
> here is the output I got after turning on CPL_DEBUG
>
> GDAL: GDALOpen(/home/dcole/eraser/Images/dan_data.ntf, this=0x1ad7ec70)
> succeeds as NITF. GDAL: QuietDelete(test1.ntf) invoking Delete()
> GDAL: GDALOpen(test1.ntf, this=0x1ad81180) succeeds as NITF.
> GDAL: GDALDefaultOverviews::OverviewScan()
> GDAL: GDALClose(test1.ntf, this=0x1ad81180)
> Warning 6: NITF only supports WGS84 geographic and UTM projections.
>
> 0GDAL: Potential thrashing on band 1 of
> /home/dcole/eraser/Images/dan_data.ntf.
> ...10...20...30...40...50...60...70...80...90...100 - done.
> ERROR 6: Apparently no space reserved for IGEOLO info in NITF file.
> NITFWriteIGEOGLO() fails.
> ERROR 6: NITF only supports WGS84 geographic and UTM projections.
>
> GDAL: GDALDefaultOverviews::OverviewScan()
> ERROR 6: NITF only supports WGS84 geographic and UTM projections.
>

This error seems to indicate that your source dataset has an incompatible
projection with what NITF allows (UTM/WGS84 and LongLat/WGS84). But this is
weird because your source dataset seems to be a NITF itself... What does
gdalinfo returns as projection for /home/dcole/eraser/Images/dan_data.ntf ?

But I don't believe it relates with performance. And I suppose you get the
same warnings when using gdal_translate.

>
> So to try to remedy th

[gdal-dev] joining shapefile to PG table

[William Kyngesburye]

I'm having a problem joining a Postgres table to a shapefile.  I've done this 
in the past with MySQL tables.

ogrinfo -al -so myshapefile.shp -sql "SELECT * FROM myshapefile LEFT JOIN 
'PG:dbname=mypgdb host=localhost user=someuser password='.mypgtable ON 
myshapefile.keyfield = mypgtable.keyfield"
INFO: Open of `myshqpefile.shp'
  using driver `ESRI Shapefile' successful.
ERROR 1: SQL Expression Parsing Error: syntax error


ogrinfo on the table works:

ogrinfo -al -so 'PG:dbname=mypgdb host=localhost user=someuser password=' 
mypgtable
INFO: Open of `PG:dbname=mypgdb host=localhost user=someuser password='
  using driver `PostgreSQL' successful.
...

I'm using a character key field (I remember problems with that in mysql), but 
that shouldn't affect the syntax.  (If GDAL 1.8 still has this limitation, 
major bummer, I'll have to convert all my shapefiles to PostGIS to join the 
tables.)


The mysql method has a tables=mypgtable parameter in the connection, but that 
doesn't help the PG connection.  Testing the mysql method (different data) 
gives me a segfault on the join, but works on the shapefile and table 
separately.  This used to work (GDAL 1.6, maybe 1.7?).

GDAL 1.8.0, Postgres 9.0.4 (both GDAL libpq and server), MySQL 5.1.52 (GDAL) & 
5.1.41 (server)

-
William Kyngesburye 
http://www.kyngchaos.com/

"We are at war with them. Neither in hatred nor revenge and with no particular 
pleasure I shall kill every ___ I can until the war is over. That is my duty."

"Don't you even hate 'em?"

"What good would it do if I did? If all the many millions of people of the 
allied nations devoted an entire year exclusively to hating the  it 
wouldn't kill one ___ nor shorten the war one day."

 "And it might give 'em all stomach ulcers."

- Tarzan, on war

___
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

[Brian Case]

Michael,

another option is to use gdalwarp to merge images together.

Brian

On Thu, 2011-07-07 at 09:47 -0700, Michael Corey wrote:
> Thanks for your responses, Chaitanya and Eli. The semitransparency isn't 
> really noticeable until you put the image on top of something else (in 
> Photoshop or another program).
> 
> It looks like the problem is actually in my gdal_merge.py command. 
> That's where the semitransparency is getting introduced.
> 
> gdal_merge.py -init "255" -o diablo-combined-utm10.tif file file file
> 
> What I'm trying to get is a merged image where no data = transparent. 
> Would this be correct in that case?
> 
> gdal_merge.py -n "255" -ul_lr 380309.272908 4653610.244134 
> 1317796.950998 3614484.073320 -o test-combined.tif file file file
> 
> Michael Corey
> Digital Innovations Editor
> Center for Investigative Reporting
> 510.809.3178
> 
> 
> On 7/7/11 7:13 AM, Eli Adam wrote:
> > 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 m

Re: [gdal-dev] joining shapefile to PG table

[Even Rouault]

Le jeudi 07 juillet 2011 21:57:31, William Kyngesburye a écrit :
> I'm having a problem joining a Postgres table to a shapefile.  I've done
> this in the past with MySQL tables.
> 
> ogrinfo -al -so myshapefile.shp -sql "SELECT * FROM myshapefile LEFT JOIN
> 'PG:dbname=mypgdb host=localhost user=someuser password='.mypgtable ON
> myshapefile.keyfield = mypgtable.keyfield" INFO: Open of `myshqpefile.shp'
>   using driver `ESRI Shapefile' successful.
> ERROR 1: SQL Expression Parsing Error: syntax error

William,

I've just tried something really close to the above and it works in trunk and 
1.8.1.

I get a segfault in 1.8.0, but the segfault can only occur if SQL parsing is 
successfull. So I don't understand why you get the SQL parsing error. I guess 
you pasted a simplified/reworked version of your exact SQL, so maybe check it 
once more...

As far as the segfault is concerned, this is an identified regression of 1.8.0 
that has been addressed in to-be-soon-released-1.8.1 (see 
http://trac.osgeo.org/gdal/ticket/4112)

Best regards,

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

Re: [gdal-dev] joining shapefile to PG table

[William Kyngesburye]

On Jul 7, 2011, at 3:17 PM, Even Rouault wrote:

> Le jeudi 07 juillet 2011 21:57:31, William Kyngesburye a écrit :
>> I'm having a problem joining a Postgres table to a shapefile.  I've done
>> this in the past with MySQL tables.
>> 
>> ogrinfo -al -so myshapefile.shp -sql "SELECT * FROM myshapefile LEFT JOIN
>> 'PG:dbname=mypgdb host=localhost user=someuser password='.mypgtable ON
>> myshapefile.keyfield = mypgtable.keyfield" INFO: Open of `myshqpefile.shp'
>>  using driver `ESRI Shapefile' successful.
>> ERROR 1: SQL Expression Parsing Error: syntax error
> 
> William,
> 
> I've just tried something really close to the above and it works in trunk and 
> 1.8.1.
> 
> I get a segfault in 1.8.0, but the segfault can only occur if SQL parsing is 
> successfull. So I don't understand why you get the SQL parsing error. I guess 
> you pasted a simplified/reworked version of your exact SQL, so maybe check it 
> once more...

Only simplified the names.  The shapefile name starts with numbers (natural 
earth shapefiles).  There's the problem.  I removed the leading numbers, and 
simplified the shapefile names to a few letters (they're also long names), no 
syntax error (segfault).  Renamed with a short name with a single leading 
number, again the syntax error.

So, it's a SQL limitation on names?

-
William Kyngesburye 
http://www.kyngchaos.com/

"Those people who most want to rule people are, ipso-facto, those least suited 
to do it."

- A rule of the universe, from the HitchHiker's Guide to the Galaxy


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

Re: [gdal-dev] joining shapefile to PG table

[Even Rouault]

> Only simplified the names.  The shapefile name starts with numbers (natural
> earth shapefiles).  There's the problem.  I removed the leading numbers,
> and simplified the shapefile names to a few letters (they're also long
> names), no syntax error (segfault).  Renamed with a short name with a
> single leading number, again the syntax error.
> 
> So, it's a SQL limitation on names?

Yes, SQL identifiers cannot start by a number without being quoted (the SQL 
engine of previous versions was perhaps a bit more tolerant, but the newer 
behaviour is closer to the one of the SQL engines you find in DBs such as 
postgres, mysql, sqlite, etc...)

I've managed to make the request work (*) by changing it like the following :

ogrinfo 123.dbf  -sql "select * from '123' onetwothree left join 
'PG:dbname=autotest port=5432'.poly on onetwothree.prfedea = poly.prfedea"

1) quote the layername after the FROM : '123'
2) just after, add an alias name for the layername : onetwothree
3) use the alias name in the ON because it won't like 123 or '123'



(*) : will crash afterwards with 1.8.0 when being evaluated...

> 
> -
> William Kyngesburye 
> http://www.kyngchaos.com/
> 
> "Those people who most want to rule people are, ipso-facto, those least
> suited to do it."
> 
> - A rule of the universe, from the HitchHiker's Guide to the Galaxy
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] joining shapefile to PG table

[William Kyngesburye]

On Jul 7, 2011, at 4:22 PM, Even Rouault wrote:

> 
>> Only simplified the names.  The shapefile name starts with numbers (natural
>> earth shapefiles).  There's the problem.  I removed the leading numbers,
>> and simplified the shapefile names to a few letters (they're also long
>> names), no syntax error (segfault).  Renamed with a short name with a
>> single leading number, again the syntax error.
>> 
>> So, it's a SQL limitation on names?
> 
> Yes, SQL identifiers cannot start by a number without being quoted (the SQL 
> engine of previous versions was perhaps a bit more tolerant, but the newer 
> behaviour is closer to the one of the SQL engines you find in DBs such as 
> postgres, mysql, sqlite, etc...)
> 
> I've managed to make the request work (*) by changing it like the following :
> 
> ogrinfo 123.dbf  -sql "select * from '123' onetwothree left join 
> 'PG:dbname=autotest port=5432'.poly on onetwothree.prfedea = poly.prfedea"
> 
> 1) quote the layername after the FROM : '123'
> 2) just after, add an alias name for the layername : onetwothree
> 3) use the alias name in the ON because it won't like 123 or '123'

Ah, sweet, I don't have to rename all my shapefiles :)  The quoting and 
aliasing works.  Thanks.

-
William Kyngesburye 
http://www.kyngchaos.com/

"History is an illusion caused by the passage of time, and time is an illusion 
caused by the passage of history."

- Hitchhiker's Guide to the Galaxy


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

RE: [gdal-dev] Creating modified copies of a file

[Cole, Derek]

So that this may help anyone in the future - it seems like I may have solved 
the problem for now! After looking through gdal_translate, it appears that they 
are using the C API instead of C++ for the CreateCopy. I switched my code to 
the C API instead of C++ just for consistency sake, and sure enough, my 
CreateCopy was sped up tremendously! 

For the smaller test file I was playing with, the output file was not viewable 
in my viewer until I made some adjustments, primarily, setting the block size 
of the copy to be the same as the original. if you dont set it explicitely you 
get row-wise blocks. 

One other quirk - I was not able to use the GDALSetCacheMax() function , and 
instead switched that to the CPLSetConfigOption() function, AND I had to move 
it to be before I call GDALAllRegister() it appears, or I was still getting 
cache thrashing warnings.

If I get some time, or if someone else does, it might be nice to narrow down 
what exactly in the C++ API was causing the problem.

Derek

From: gdal-dev-boun...@lists.osgeo.org [gdal-dev-boun...@lists.osgeo.org] on 
behalf of Cole, Derek [dc...@integrity-apps.com]
Sent: Thursday, July 07, 2011 3:20 PM
To: gdal-dev@lists.osgeo.org
Subject: RE: [gdal-dev] Creating modified copies of a file

I actually just out of curiosity tried to open the file given by this command:

gdal_translate dan_data.ntf dan_data_translate.ntf

And it turns out that dan_data_translate.ntf was actually a TIFF file that I 
could view. I had to explicitly add the option -of NITF

in which case it still did the translate very fast, but I did get warnings:

$ gdal_translate dan_data.ntf dan_data_translate.ntf -of NITF
Input file size is 8689, 7679
Warning 6: NITF only supports WGS84 geographic and UTM projections.

0...10...20...30...40...50...60...70...80...90...100 - done.
ERROR 6: Apparently no space reserved for IGEOLO info in NITF file.
NITFWriteIGEOGLO() fails.
ERROR 6: NITF only supports WGS84 geographic and UTM projections.


Which jives with what my code was giving me, and further, 
dan_data_translate.ntf is not able to be opened using my viewer (which uses 
GDAL to open the files I have been working with, of course, and does open 
dan_data.ntf) because of a segmentation fault  in the RasterIO method. I am 
able to open the gdal_translate file, and my CreateCopy() file in another ELT, 
such as ENVI.

I will also make note that the original file is exactly 72.0 MB, and the output 
file is 63.6MB, but both files say in gdalinfo they are not using compression. 
This is the same for my CreateCopy() or gdal_translate. So at least I have 
narrowed down that I am apparently getting the same end-result as 
gdal_translate, albeit way slower. Finally, the output file seems to have 
created row-blocks, instead of 1024x1024 blocks like the original.

I will continue working to replicate gdal_translate exactly, even though now i 
am not optimistic about getting a good result.


From: gdal-dev-boun...@lists.osgeo.org [gdal-dev-boun...@lists.osgeo.org] on 
behalf of Cole, Derek [dc...@integrity-apps.com]
Sent: Thursday, July 07, 2011 2:48 PM
To: gdal-dev@lists.osgeo.org
Subject: RE: [gdal-dev] Creating modified copies of a file

Yes, the source data is a NITF. Here is the first few lines of the projection 
info  in that source NITF:
Coordinate System is:
PROJCS["unnamed",
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.257223563,
AUTHORITY["EPSG","7030"]],
TOWGS84[0,0,0,0,0,0,0],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0,
AUTHORITY["EPSG","8901"]],
UNIT["degree",0.0174532925199433,
AUTHORITY["EPSG","9108"]],
AUTHORITY["EPSG","4326"]],
PROJECTION["Transverse_Mercator"],
PARAMETER["latitude_of_origin",0],
PARAMETER["central_meridian",-75],
PARAMETER["scale_factor",0.996],
PARAMETER["false_easting",50],
PARAMETER["false_northing",0]]


I suppose I can go back through my code and change it to be exactly like 
gdal_translate, which seems to use the C bindings instead of C++.  I did end up 
changing my progress reporting function to the same one that is in 
gdal_translate as well, which had no change. I will try the debugging route 
before too much trouble, to see what I can find out.

Thanks for the help so far. I will report back what I find.




From: Even Rouault [even.roua...@mines-paris.org]
Sent: Thursday, July 07, 2011 2:13 PM
To: gdal-dev@lists.osgeo.org
Cc: Cole, Derek
Subject: Re: [gdal-dev] Creating modified copies of a file

Le jeudi 07 juillet 2011 19:52:34, Cole, Derek a écrit :
> Well, I am about to give up on this I think and go a different route for
> creating a NITF from this data.
>
> I tried a small test file, and it takes about 45s to CopyCrate() an 80mb
> NITF.

Yes, that's very poor performan

Re: [gdal-dev] Creating modified copies of a file

[Even Rouault]

Le jeudi 07 juillet 2011 23:46:11, Cole, Derek a écrit :
> So that this may help anyone in the future - it seems like I may have
> solved the problem for now! After looking through gdal_translate, it
> appears that they are using the C API instead of C++ for the CreateCopy. I
> switched my code to the C API instead of C++ just for consistency sake,
> and sure enough, my CreateCopy was sped up tremendously!

Really ??? That doesn't make any sense. The C function GDALCreateCopy() is 
just a one line wrapper over the C++ API. I'm 200% sure there must be another 
difference in the values of the arguments between your C and C++ call. You 
should recheck...

> 
> For the smaller test file I was playing with, the output file was not
> viewable in my viewer until I made some adjustments, primarily, setting
> the block size of the copy to be the same as the original. if you dont set
> it explicitely you get row-wise blocks.

Yes, row-wise blocks are the default. Tiling must be explicitely set up with 
teh BLOCKXSIZE and BLOCKYSIZE creation options.

> 
> One other quirk - I was not able to use the GDALSetCacheMax() function ,

What do you mean by "not being able to use the GDALSetCacheMax()" ? Are you 
sure you specified the value in bytes as specified in the doc. I suspect you 
must have set a value in megabytes, because when the GDAL_CACHEMAX 
configuration option is read, there's a magic to automatically multiply small 
values (< 10) by one million. That could explain why you manage to achieve 
the desired effect by using CPLSetConfigOption().

> and instead switched that to the CPLSetConfigOption() function, AND I had
> to move it to be before I call GDALAllRegister() it appears, or I was
> still getting cache thrashing warnings.
> 
> If I get some time, or if someone else does, it might be nice to narrow
> down what exactly in the C++ API was causing the problem.
> 
> Derek
> 
> From: gdal-dev-boun...@lists.osgeo.org [gdal-dev-boun...@lists.osgeo.org]
> on behalf of Cole, Derek [dc...@integrity-apps.com] Sent: Thursday, July
> 07, 2011 3:20 PM
> To: gdal-dev@lists.osgeo.org
> Subject: RE: [gdal-dev] Creating modified copies of a file
> 
> I actually just out of curiosity tried to open the file given by this
> command:
> 
> gdal_translate dan_data.ntf dan_data_translate.ntf
> 
> And it turns out that dan_data_translate.ntf was actually a TIFF file that
> I could view. I had to explicitly add the option -of NITF
> 
> in which case it still did the translate very fast, but I did get warnings:
> 
> $ gdal_translate dan_data.ntf dan_data_translate.ntf -of NITF
> Input file size is 8689, 7679
> Warning 6: NITF only supports WGS84 geographic and UTM projections.
> 
> 0...10...20...30...40...50...60...70...80...90...100 - done.
> ERROR 6: Apparently no space reserved for IGEOLO info in NITF file.
> NITFWriteIGEOGLO() fails.
> ERROR 6: NITF only supports WGS84 geographic and UTM projections.
> 
> 
> Which jives with what my code was giving me, and further,
> dan_data_translate.ntf is not able to be opened using my viewer (which
> uses GDAL to open the files I have been working with, of course, and does
> open dan_data.ntf) because of a segmentation fault  in the RasterIO
> method. I am able to open the gdal_translate file, and my CreateCopy()
> file in another ELT, such as ENVI.
> 
> I will also make note that the original file is exactly 72.0 MB, and the
> output file is 63.6MB, but both files say in gdalinfo they are not using
> compression. This is the same for my CreateCopy() or gdal_translate. So at
> least I have narrowed down that I am apparently getting the same
> end-result as gdal_translate, albeit way slower. Finally, the output file
> seems to have created row-blocks, instead of 1024x1024 blocks like the
> original.
> 
> I will continue working to replicate gdal_translate exactly, even though
> now i am not optimistic about getting a good result.
> 
> 
> From: gdal-dev-boun...@lists.osgeo.org [gdal-dev-boun...@lists.osgeo.org]
> on behalf of Cole, Derek [dc...@integrity-apps.com] Sent: Thursday, July
> 07, 2011 2:48 PM
> To: gdal-dev@lists.osgeo.org
> Subject: RE: [gdal-dev] Creating modified copies of a file
> 
> Yes, the source data is a NITF. Here is the first few lines of the
> projection info  in that source NITF: Coordinate System is:
> PROJCS["unnamed",
> GEOGCS["WGS 84",
> DATUM["WGS_1984",
> SPHEROID["WGS 84",6378137,298.257223563,
> AUTHORITY["EPSG","7030"]],
> TOWGS84[0,0,0,0,0,0,0],
> AUTHORITY["EPSG","6326"]],
> PRIMEM["Greenwich",0,
> AUTHORITY["EPSG","8901"]],
> UNIT["degree",0.0174532925199433,
> AUTHORITY["EPSG","9108"]],
> AUTHORITY["EPSG","4326"]],
> PROJECTION["Transverse_Mercator"],
> PARAMETER["latitude_of_origin",0],
> PARAMETER["central_meridian",-75],
> PARAMETER["scale_fact

RE: [gdal-dev] Creating modified copies of a file

[Cole, Derek]

C:

GDALDatasetHhDataset, hOutDS;
const char  *pszSource=NULL, *pszDest=NULL, *pszFormat = 
"NITF";
char**papszCreateOptions = NULL;
GDALProgressFuncpfnProgress = GDALTermProgress;
GDALDriverH hDriver;

hDriver = GDALGetDriverByName( pszFormat );
pszSource = this->loadedFile.toStdString().c_str();
pszDest = "testout.ntf";
hDataset = GDALOpenShared( pszSource, GA_ReadOnly );

char **papszOptions = NULL;

papszOptions = CSLSetNameValue( papszOptions, "BLOCKXSIZE", "1024" );
papszOptions = CSLSetNameValue( papszOptions, "BLOCKYSIZE", "1024" );
papszOptions = CSLSetNameValue( papszOptions, "ABPP", "11" );

hOutDS = GDALCreateCopy( hDriver, pszDest, hDataset, FALSE, papszOptions, 
pfnProgress, NULL );

C++:

 GDALProgressFuncpfnProgress = GDALTermProgress;
const char *pszFormat = "NITF";
GDALDataset *poNITFDS;
char ** papszMetadata;
GDALDriver *poNITFDriver;
GDALDataset  *poDataset;
const char *pszDstFilename = "test1.ntf";

poDataset = (GDALDataset *) GDALOpenShared( 
this->loadedFile.toStdString().c_str(), GA_ReadOnly );

poNITFDriver = (GDALDriver *)GDALGetDriverByName("NITF");
papszMetadata = poNITFDriver->GetMetadata();

if( poNITFDriver == NULL )
exit( 1 );

char **papszOptions = NULL;

const char *srcProjection = poDataset->GetGCPProjection();

papszOptions = CSLSetNameValue( papszOptions, "BLOCKXSIZE", "1024" );
papszOptions = CSLSetNameValue( papszOptions, "BLOCKYSIZE", "1024" );
papszOptions = CSLSetNameValue( papszOptions, "ABPP", "11" );

poNITFDS = poNITFDriver->CreateCopy(pszDstFilename, poDataset, FALSE,  
papszOptions, pfnProgress, NULL);


Perhaps you can tell me. These are the direct copies of the two latest versions 
of the code I tried. It could very well be that if I tried the C++ version 
again with the cache storage values corrected, it would speed up. I may try 
that just to make sure. 

Also, you may be right about the cache options. I noticed just now in the API 
declaration, it calls the variable nBytes, but down in the API it just calls it 
nNewSize, and I think I had read somewhere that the command line option was in 
MB, so that may be my bad. Is my assertion that it must come before registering 
drivers correct?


From: Even Rouault [even.roua...@mines-paris.org]
Sent: Thursday, July 07, 2011 6:07 PM
To: gdal-dev@lists.osgeo.org
Cc: Cole, Derek
Subject: Re: [gdal-dev] Creating modified copies of a file

Le jeudi 07 juillet 2011 23:46:11, Cole, Derek a écrit :
> So that this may help anyone in the future - it seems like I may have
> solved the problem for now! After looking through gdal_translate, it
> appears that they are using the C API instead of C++ for the CreateCopy. I
> switched my code to the C API instead of C++ just for consistency sake,
> and sure enough, my CreateCopy was sped up tremendously!

Really ??? That doesn't make any sense. The C function GDALCreateCopy() is
just a one line wrapper over the C++ API. I'm 200% sure there must be another
difference in the values of the arguments between your C and C++ call. You
should recheck...

>
> For the smaller test file I was playing with, the output file was not
> viewable in my viewer until I made some adjustments, primarily, setting
> the block size of the copy to be the same as the original. if you dont set
> it explicitely you get row-wise blocks.

Yes, row-wise blocks are the default. Tiling must be explicitely set up with
teh BLOCKXSIZE and BLOCKYSIZE creation options.

>
> One other quirk - I was not able to use the GDALSetCacheMax() function ,

What do you mean by "not being able to use the GDALSetCacheMax()" ? Are you
sure you specified the value in bytes as specified in the doc. I suspect you
must have set a value in megabytes, because when the GDAL_CACHEMAX
configuration option is read, there's a magic to automatically multiply small
values (< 10) by one million. That could explain why you manage to achieve
the desired effect by using CPLSetConfigOption().

> and instead switched that to the CPLSetConfigOption() function, AND I had
> to move it to be before I call GDALAllRegister() it appears, or I was
> still getting cache thrashing warnings.
>
> If I get some time, or if someone else does, it might be nice to narrow
> down what exactly in the C++ API was causing the problem.
>
> Derek
> 
> From: gdal-dev-boun...@lists.osgeo.org [gdal-dev-boun...@lists.osgeo.org]
> on behalf of Cole, Derek [dc...@integrity-apps.com] Sent: Thursday, July
> 07, 2011 3:20 PM
> To: gdal-dev@lists.osgeo.org
> Subject: RE: [gdal-dev] Creating modified copies of a file
>
> I actually just out of curiosity tried to open the file given by this
> command:
>
> gdal_translate dan_data.ntf dan_data_translate.ntf
>
> And it turns out that dan_data_translate.

RE: [gdal-dev] Creating modified copies of a file

[Cole, Derek]

Even, thanks for the help by the way. Hopefully I can return the favor some 
day, as it looks like I am going to be getting quite familiar with this.

I think the caching value was the issue perhaps, and I just happened to get it 
working correclty in the C version. Oh well, at least if someone finds this 
thread, they can see both ways of doing it.

Derek

From: gdal-dev-boun...@lists.osgeo.org [gdal-dev-boun...@lists.osgeo.org] on 
behalf of Cole, Derek [dc...@integrity-apps.com]
Sent: Thursday, July 07, 2011 6:20 PM
To: gdal-dev@lists.osgeo.org
Subject: RE: [gdal-dev] Creating modified copies of a file

NOTICE:  A potentially dangerous attachment(s) to this email was identified.  
Please do NOT open any attachments, unless you are expecting them, and they are 
from a trusted source, as unsolicited attachments can contain malware.  Please 
call the Helpdesk @ x.275 for assistance or questions.

Thank you,
The IAI IT Team

C:

GDALDatasetHhDataset, hOutDS;
const char  *pszSource=NULL, *pszDest=NULL, *pszFormat = 
"NITF";
char**papszCreateOptions = NULL;
GDALProgressFuncpfnProgress = GDALTermProgress;
GDALDriverH hDriver;

hDriver = GDALGetDriverByName( pszFormat );
pszSource = this->loadedFile.toStdString().c_str();
pszDest = "testout.ntf";
hDataset = GDALOpenShared( pszSource, GA_ReadOnly );

char **papszOptions = NULL;

papszOptions = CSLSetNameValue( papszOptions, "BLOCKXSIZE", "1024" );
papszOptions = CSLSetNameValue( papszOptions, "BLOCKYSIZE", "1024" );
papszOptions = CSLSetNameValue( papszOptions, "ABPP", "11" );

hOutDS = GDALCreateCopy( hDriver, pszDest, hDataset, FALSE, papszOptions, 
pfnProgress, NULL );

C++:

 GDALProgressFuncpfnProgress = GDALTermProgress;
const char *pszFormat = "NITF";
GDALDataset *poNITFDS;
char ** papszMetadata;
GDALDriver *poNITFDriver;
GDALDataset  *poDataset;
const char *pszDstFilename = "test1.ntf";

poDataset = (GDALDataset *) GDALOpenShared( 
this->loadedFile.toStdString().c_str(), GA_ReadOnly );

poNITFDriver = (GDALDriver *)GDALGetDriverByName("NITF");
papszMetadata = poNITFDriver->GetMetadata();

if( poNITFDriver == NULL )
exit( 1 );

char **papszOptions = NULL;

const char *srcProjection = poDataset->GetGCPProjection();

papszOptions = CSLSetNameValue( papszOptions, "BLOCKXSIZE", "1024" );
papszOptions = CSLSetNameValue( papszOptions, "BLOCKYSIZE", "1024" );
papszOptions = CSLSetNameValue( papszOptions, "ABPP", "11" );

poNITFDS = poNITFDriver->CreateCopy(pszDstFilename, poDataset, FALSE,  
papszOptions, pfnProgress, NULL);


Perhaps you can tell me. These are the direct copies of the two latest versions 
of the code I tried. It could very well be that if I tried the C++ version 
again with the cache storage values corrected, it would speed up. I may try 
that just to make sure.

Also, you may be right about the cache options. I noticed just now in the API 
declaration, it calls the variable nBytes, but down in the API it just calls it 
nNewSize, and I think I had read somewhere that the command line option was in 
MB, so that may be my bad. Is my assertion that it must come before registering 
drivers correct?


From: Even Rouault [even.roua...@mines-paris.org]
Sent: Thursday, July 07, 2011 6:07 PM
To: gdal-dev@lists.osgeo.org
Cc: Cole, Derek
Subject: Re: [gdal-dev] Creating modified copies of a file

Le jeudi 07 juillet 2011 23:46:11, Cole, Derek a écrit :
> So that this may help anyone in the future - it seems like I may have
> solved the problem for now! After looking through gdal_translate, it
> appears that they are using the C API instead of C++ for the CreateCopy. I
> switched my code to the C API instead of C++ just for consistency sake,
> and sure enough, my CreateCopy was sped up tremendously!

Really ??? That doesn't make any sense. The C function GDALCreateCopy() is
just a one line wrapper over the C++ API. I'm 200% sure there must be another
difference in the values of the arguments between your C and C++ call. You
should recheck...

>
> For the smaller test file I was playing with, the output file was not
> viewable in my viewer until I made some adjustments, primarily, setting
> the block size of the copy to be the same as the original. if you dont set
> it explicitely you get row-wise blocks.

Yes, row-wise blocks are the default. Tiling must be explicitely set up with
teh BLOCKXSIZE and BLOCKYSIZE creation options.

>
> One other quirk - I was not able to use the GDALSetCacheMax() function ,

What do you mean by "not being able to use the GDALSetCacheMax()" ? Are you
sure you specified the value in bytes as specified in the doc. I suspect you
must have set a value in megabytes, because when the GDAL_CACHEMAX
configuration option is read, there's a magic to automati

Re: [gdal-dev] Creating modified copies of a file

[Even Rouault]

Le vendredi 08 juillet 2011 00:25:04, Cole, Derek a écrit :
> Even, thanks for the help by the way. Hopefully I can return the favor some
> day, as it looks like I am going to be getting quite familiar with this.
> 
> I think the caching value was the issue perhaps, 

Yes certainly, if you provided a very small value to GDALSetCacheMax() 
(smaller than the size of one block), you will run into very intensive cache 
trashing because you won't have enough memory to store more than one block at 
a time... And that can cause terrible performance due to a huge number of I/O 
access.

And to answer the question of your previous email, if you set the 
GDAL_CACHEMAX configuration option, you must do it before the first time GDAL 
tries to access to it internally, so in practice, to be safe, before 
initializing GDAL with GDALAllRegister(). Indeed, after the first access, the 
value is stored into an internal variable and isn't read any more from the 
configuration option.

> and I just happened to get
> it working correclty in the C version. Oh well, at least if someone finds
> this thread, they can see both ways of doing it.
> 
> Derek
> 
> From: gdal-dev-boun...@lists.osgeo.org [gdal-dev-boun...@lists.osgeo.org]
> on behalf of Cole, Derek [dc...@integrity-apps.com] Sent: Thursday, July
> 07, 2011 6:20 PM
> To: gdal-dev@lists.osgeo.org
> Subject: RE: [gdal-dev] Creating modified copies of a file
> 
> NOTICE:  A potentially dangerous attachment(s) to this email was
> identified.  Please do NOT open any attachments, unless you are expecting
> them, and they are from a trusted source, as unsolicited attachments can
> contain malware.  Please call the Helpdesk @ x.275 for assistance or
> questions.
> 
> Thank you,
> The IAI IT Team
> 
> C:
> 
> GDALDatasetHhDataset, hOutDS;
> const char  *pszSource=NULL, *pszDest=NULL, *pszFormat
> = "NITF"; char**papszCreateOptions = NULL;
> GDALProgressFuncpfnProgress = GDALTermProgress;
> GDALDriverH hDriver;
> 
> hDriver = GDALGetDriverByName( pszFormat );
> pszSource = this->loadedFile.toStdString().c_str();
> pszDest = "testout.ntf";
> hDataset = GDALOpenShared( pszSource, GA_ReadOnly );
> 
> char **papszOptions = NULL;
> 
> papszOptions = CSLSetNameValue( papszOptions, "BLOCKXSIZE", "1024" );
> papszOptions = CSLSetNameValue( papszOptions, "BLOCKYSIZE", "1024" );
> papszOptions = CSLSetNameValue( papszOptions, "ABPP", "11" );
> 
> hOutDS = GDALCreateCopy( hDriver, pszDest, hDataset, FALSE,
> papszOptions, pfnProgress, NULL );
> 
> C++:
> 
>  GDALProgressFuncpfnProgress = GDALTermProgress;
> const char *pszFormat = "NITF";
> GDALDataset *poNITFDS;
> char ** papszMetadata;
> GDALDriver *poNITFDriver;
> GDALDataset  *poDataset;
> const char *pszDstFilename = "test1.ntf";
> 
> poDataset = (GDALDataset *) GDALOpenShared(
> this->loadedFile.toStdString().c_str(), GA_ReadOnly );
> 
> poNITFDriver = (GDALDriver *)GDALGetDriverByName("NITF");
> papszMetadata = poNITFDriver->GetMetadata();
> 
> if( poNITFDriver == NULL )
> exit( 1 );
> 
> char **papszOptions = NULL;
> 
> const char *srcProjection = poDataset->GetGCPProjection();
> 
> papszOptions = CSLSetNameValue( papszOptions, "BLOCKXSIZE", "1024" );
> papszOptions = CSLSetNameValue( papszOptions, "BLOCKYSIZE", "1024" );
> papszOptions = CSLSetNameValue( papszOptions, "ABPP", "11" );
> 
> poNITFDS = poNITFDriver->CreateCopy(pszDstFilename, poDataset, FALSE, 
> papszOptions, pfnProgress, NULL);
> 
> 
> Perhaps you can tell me. These are the direct copies of the two latest
> versions of the code I tried. It could very well be that if I tried the
> C++ version again with the cache storage values corrected, it would speed
> up. I may try that just to make sure.
> 
> Also, you may be right about the cache options. I noticed just now in the
> API declaration, it calls the variable nBytes, but down in the API it just
> calls it nNewSize, and I think I had read somewhere that the command line
> option was in MB, so that may be my bad. Is my assertion that it must come
> before registering drivers correct?
> 
> 
> From: Even Rouault [even.roua...@mines-paris.org]
> Sent: Thursday, July 07, 2011 6:07 PM
> To: gdal-dev@lists.osgeo.org
> Cc: Cole, Derek
> Subject: Re: [gdal-dev] Creating modified copies of a file
> 
> Le jeudi 07 juillet 2011 23:46:11, Cole, Derek a écrit :
> > So that this may help anyone in the future - it seems like I may have
> > solved the problem for now! After looking through gdal_translate, it
> > appears that they are using the C API instead of C++ for the CreateCopy.
> > I switched my code to the C API instead of C++ just for consistency
> > sake, and sure enough, my CreateCopy was sped up tremendously!
> 
> Really ??? That doesn't make any sense. T

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

[katrin eggert]

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

[katrin eggert]

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

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.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]

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] gdalwarp over tiles in Plate carée

[Nikolaos Hatzopoulos]

I haven't worked with MERIS on NDVI data but I know about MODIS:

so let's say we have four MODIS files lvl3 data:
MOD13Q1.A2010113.h08v04.005.2010133194933.hdf
MOD13Q1.A2010113.h08v05.005.2010134041223.hdf
MOD13Q1.A2010113.h09v04.005.2010135200404.hdf
MOD13Q1.A2010113.h09v05.005.2010133080730.hdf

if you go to the map:
https://lpdaac.usgs.gov/lpdaac/products/modis_overview

you are going to see that these tiles represent the west coast

what I do is extract the data from hdf to geotiff

if you do gdalinfo MOD13Q1.A2010113.h08v04.005.2010133194933.hdf

you are going to have:
...
 
SUBDATASET_2_NAME=HDF4_EOS:EOS_GRID:"MOD13Q1.A2010113.h08v04.005.2010133194933.hdf":MODIS_Grid_16DAY_250m_500m_VI:250m
16 days EVI
  SUBDATASET_2_DESC=[4800x4800] 250m 16 days EVI
MODIS_Grid_16DAY_250m_500m_VI (16-bit integer)

SUBDATASET_3_NAME=HDF4_EOS:EOS_GRID:"MOD13Q1.A2010113.h08v04.005.2010133194933.hdf":MODIS_Grid_16DAY_250m_500m_VI:250m
16 days VI Quality
  SUBDATASET_3_DESC=[4800x4800] 250m 16 days VI Quality
MODIS_Grid_16DAY_250m_500m_VI (16-bit unsigned integer)

SUBDATASET_4_NAME=HDF4_EOS:EOS_GRID:"MOD13Q1.A2010113.h08v04.005.2010133194933.hdf":MODIS_Grid_16DAY_250m_500m_VI:250m
16 days red reflectance
  SUBDATASET_4_DESC=[4800x4800] 250m 16 days red reflectance
MODIS_Grid_16DAY_250m_500m_VI (16-bit integer)

...

you do:

gdal_translate
'HDF4_EOS:EOS_GRID:"MOD13Q1.A2010113.h08v04.005.2010133194933.hdf":MODIS_Grid_16DAY_250m_500m_VI:250m
16 days NDVI' image1.tif
0...10...20...30...40...50...60...70...80...90...100 - done.

so you will have your first tif

you do the same for the others files

and you will have:
image1.tif
image2.tif
image3.tif
image4.tif

we are going to make a virtual mosaic using the vrt format:

gdalbuildvrt mosaic.vrt *.tif

if you open in a text editor the mosaic .vrt you are going to see the
details

now we are going to convert the mosaic to WGS84 projection
gdalwarp -t_srs WGS84 mosaic.vrt final.tif

my final.tif does not have any lines

On Thu, Jul 7, 2011 at 5:02 PM, katrin eggert wrote:

> 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
>
> ___
> 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] Fwd: Re: [Live-demo] Re: Liberal licensing of Project Overviews in LiveDVD, do we want this?

[Even Rouault]

Hi,

below Simon's answer to my answers to his post on the live-demo list :
http://lists.osgeo.org/pipermail/live-demo/2011-July/003653.html

Do you have opinions on how we should handle the licence of documentation on 
gdal.org ?

Best regards,

Even
--- Begin Message ---

On 06/07/11 18:12, Even Rouault wrote:

All doc living on gdal.org is automatically generated from the content of the
GDAL/OGR subversion repository, so it comes from GDAL commiters that have agreed
to submit their contributions under the X/MIT licence terms. Thus, I would tend
to think that the doc taken from there can be used under those terms or
equivalently liberal licencing terms (looks like CC-BY might be the closest
equivalent, perhaps CC0 ?, but I'm not familiar with CC licences).


The GDAL project came under my Group 1 'No copyright specified on the 
website'.


Some points worth considering...
1. Not specifying a licence means the work's copyright defaults to the 
copyright laws for the jurisdiction the work was published, not to 
something used elsewhere even if it is a permissive licence..
2. The website should be updated to identify that the documentation is 
covered under MIT licence and point to the deed as several versions of 
this licence is in existence.



As far as my contributions are concerned (almost nothing on the main page
actually, mainly in drivers or API documentation), I'm fine that they are reused
under any free licence you see fit. But this is just my personal opinion, not
necessarily the official one from the project or its other contributors,
although I'd be surprised that anyone would oppose to making it available under
terms appropriate for it to be used by osgeo-live.


If people have contributed code and documentation under a general MIT 
licence...


Copyright (C)  by 

Permission is hereby granted, free of charge, to any person obtaining a 
copy of this software and *associated documentation files* (the 
"Software"), to deal in the Software without restriction, including 
without limitation the rights to use, copy, modify, merge, publish, 
distribute, sublicense, and/or sell copies of the Software, and to 
permit persons to whom the Software is furnished to do so, subject to 
the following conditions:


*The above copyright notice and this permission notice shall be included 
in all copies or substantial portions of the Software.*


THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 
OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. 
IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY 
CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, 
TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE 
SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

http://en.wikipedia.org/wiki/MIT_License

This is not equivalent to CC-BY. No attribution is necessary. The only 
requirement is reproduction of the above notice with all derivatives. 
Something not currently being done by on the LiveDVD.


Further discussion on the issue can be found here...
http://wiki.creativecommons.org/Version_3#MIT

--
Cheers Simon

   Simon Cropper
   Principal Consultant
   Botanicus Australia Pty Ltd
   PO Box 160, Sunshine, VIC
   W: www.botanicusaustralia.com.au

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

[gdal-dev] SetAttributeFilter has no effect ?

[ahmet temiz]

hello

I tried to implement SetAttributeFilter with a critaria.
 There seems to have no effect on getting data.

what might be wrong ?

I am still getting all data

here is the code fragment.

ly2.SetAttributeFilter("il='kastamonu'");


for (int i = 0;i<1244; i++) {
Feature f = ly2.GetFeature(i);
System.out.print(f.GetFID());
System.out.println(" " + f.GetFieldAsString("il"));
System.out.println(" " + f.GetFieldAsString("ilce"));
System.out.println(" " + f.GetFieldAsString("koy"));
System.out.println(" " + 
f.GetFieldAsString("etkili_nak"));
//System.out.println(" " + f.GetFieldAsString("lkod"));


out.print(f.GetFID());
out.print(" " + f.GetFieldAsString("il"));
out.println(" " + f.GetFieldAsString("koy"));

}


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