Re: [gdal-dev] Contour Gaps

[zeta]

> Lots of assumptions, lots of dependencies on how convoluted the contours
> are, the ratio of the gap length to contour spacing (in
> the horizontal plane) etc. and how much automation and inspection you
> can tolerate. Do you have Z values for the contours? Or any common
> attribute which shares across the gaps?

Michael,

in my previous discussion with Chaitanya I attached sample images. Although I 
can label Z values, as can be seen from those sample images, it will requite 
too much manual work because of the gaps, which is just the same as if I use 
the time to close gaps manually.

I thought that there is some general approach to solve this problem, and that 
gdal list is where I can be advised like couple of times before.

I'll do more searching and if nothing comes out, I'll take the image with gaps 
through python/scipy, and then:
 - do spline fit on existing lines and connect all gap points within certain 
radius,
 - find some sweet spot depending on connected curves direction angle and 
connection line direction angle
 - decide which connection line to keep

If this approach fails for some reason, there is backup plan to tangle myself 
with Voronoi diagrams and Delaunay triangulations, which I hope would require 
less time than doing vectorization by hand.

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

Re: [gdal-dev] Closing disconnected contours

[zeta]

Chaitanya kumar CH wrote:
>
>gdal_fillnodata is intended for raster images, like a DEM. Your image is a
>rendered map.
>The image you provided is not suitable for unsupervised processing,
>especially with GDAL.

OK than, Chaitanya, thanks for letting me know.

Cheers

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

Re: [gdal-dev] Closing disconnected contours

[Chaitanya kumar CH]

zeta,

gdal_fillnodata is intended for raster images, like a DEM. Your image is a
rendered map.
The image you provided is not suitable for unsupervised processing,
especially with GDAL.


On Tue, Feb 26, 2013 at 12:53 PM, zeta  wrote:

> Chaitanya kumar CH wrote:
> >
> >Are the lines in topo.tif contour lines? How did you generate them?
>
>
> Hi Chaitanya,
>
> I segmented scanned image, and then did thinning on separation that
> interested me - that is topo contours. Here is link to a part of scanned
> image that I used as example: http://i.imgur.com/Wyv147m.png
>
> I thought also that maybe gdal_fillnodata.py doesn't like thinning (1px
> contours) and I did dilation on same image to get topo contours with 3px
> width, but result was worse.
> Did I expected too much, or maybe my image wasn't prepared corectly for
> gdal algorithm used in gdal_fillnodata.py?
>
>


-- 
Best regards,
Chaitanya kumar CH.

+91-9494447584
17.2416N 80.1426E
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Closing disconnected contours

[zeta]

Chaitanya kumar CH wrote:
>
>Are the lines in topo.tif contour lines? How did you generate them?


Hi Chaitanya,

I segmented scanned image, and then did thinning on separation that interested 
me - that is topo contours. Here is link to a part of scanned image that I used 
as example: http://i.imgur.com/Wyv147m.png

I thought also that maybe gdal_fillnodata.py doesn't like thinning (1px 
contours) and I did dilation on same image to get topo contours with 3px width, 
but result was worse.
Did I expected too much, or maybe my image wasn't prepared corectly for gdal 
algorithm used in gdal_fillnodata.py?

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

Re: [gdal-dev] Closing disconnected contours

[Chaitanya kumar CH]

zeta,

Are the lines in topo.tif contour lines? How did you generate them?


On Tue, Feb 26, 2013 at 12:20 AM, zeta  wrote:

> Chaitanya kumar CH wrote:
> >
> >zeta,
> >
> >The gaps are likely caused by pixels with no data. A simple method is to
> >run gdal_fillnodata.py on the original raster and then create the
> contours.
> >
> >http://www.gdal.org/gdal_fillnodata.html
>
> Thanks Chaitanya,
>
> that's excellent news, as I previously searched for algorithms about curve
> reconstruction, and none seemed easy for implementation. I was driven by
> approach using Delaunay Triangulation,  referenced to Amenta "The crust and
> the beta -skeleton: Combinatorial curve reconstruction" and plastically
>  explained i.e. here:
> http://valis.cs.uiuc.edu/~sariel/research/CG/applets/Crust/Crust.html but
> I thought to look for shortcut if possible, without reinventing
> implementation.
>
> I tried the script, and I get some gaps filled, but most aren't. I used
> -md parameter of 20px, but changed that value from 10 to 300 without
> significant improvement. Then I used mask file, which I assume works as in
> OpenCV Inpaint function, by using mask as a helper for gap detection, but
> without success.
>
> I'm attaching example image, and mask image, which I used to test the
> script, in a hope that someone can tell me if better results are possible.
>
> Thanks




-- 
Best regards,
Chaitanya kumar CH.

+91-9494447584
17.2416N 80.1426E
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Contour Gaps

[Michael Patrick]

> I have shape file from sample map, consisting of topological contours.
However many contours have small gaps and I'm looking for a pointer how to
connect those lines, automatically. Does ogr have a method or maybe more
generally does anyone know of a tool, that would correctly close
disconnected contours, which aren't labeled? Gaps are small - artifacts
from graticules present in original image used as source for creating this
vector.

Lots of assumptions, lots of dependencies on how convoluted the contours
are, the ratio of the gap length to contour spacing (in
the horizontal plane) etc. and how much automation and inspection you
can tolerate. Do you have Z values for the contours? Or any common
attribute which shares across the gaps?

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

Re: [gdal-dev] Georeference EUMETSAT's NDVI (hdf5)

[Simon Richard Proud]

Hi,
I use the following to warp SEVIRI images:

ulx_msg=-5570248.832537
uly_msg=5570248.832537
lrx_msg=5567248.429179
lry_msg=-5567248.429179
gdal_translate -a_srs  "+proj=geos +a=6378169 +b=6356583.8 +lon_0=0 
+h=35785831" -a_ullr $ulx_msg $uly_msg $lrx_msg $lry_msg (infile) (outfile)
gdalwarp -s_srs '+proj=geos +lon_0=0.0 +h=35785831 +x_0=0.0' -t_srs 
'+proj=latlong +datum=WGS84' -tr 0.04 0.04 -te -40 -40 40 40 -order 3 (infile) 
(outfile)

The correct parameters for a, b, lon_0 and h can be found from the weekly MSG 
position reports, the above values were valid for MSG-2 in late December. 
Change -tr and -te as needed for whatever geographical area you're interested 
in.
Hope that helps,
Simon

From: gdal-dev-boun...@lists.osgeo.org [gdal-dev-boun...@lists.osgeo.org] on 
behalf of Johannes Landmann [j_landm...@gmx.de]
Sent: 25 February 2013 20:27
To: gdal-dev@lists.osgeo.org
Subject: [gdal-dev] Georeference EUMETSAT's NDVI (hdf5)

Dear GDAL-friends,

I am quite new to GDAL and I've got a substantial question:

For my bachelor thesis I work with EUMETSAT's NDVI data published in HDF5 
format. These data are "produced" in the geostationary satellite projection but 
do not contain geospatial reference in the HDF5 dataset.

I have already tried out to assign the projection to the images with  "gdalwarp 
-s_srs SR-ORG:81" as well as "gdalwarp -t_srs SR-ORG:81" but with no result.

What am I doing wrong? Is there another (better) way to "reassign" the 
projection?

Thanks in advance,

Johannes
___
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] Georeference EUMETSAT's NDVI (hdf5)

[Frank Warmerdam]

Johannes,

I do not believe you can refer to spatialreference.org coordinate
systems using the SR-ORG: format.  I see things may work with:

gdalsrsinfo http://spatialreference.org/ref/sr-org/81/

If the HDF5 datasets have an affine transformation set already in the
geostationary projection you may find that this works:

gdalwarp -s_srs http://spatialreference.org/ref/sr-org/81/ -t_srs
 in.tif out.tif

to reproject or or even:

gdal_translate -a_srs  http://spatialreference.org/ref/sr-org/81/ in.tif out.tif

to just assign the coordinate system to the file.

If the source file doesn't have the affine transformation set properly
you will need to set that too with gdal_translate, using -a_ullr.

In cases like this it is helpful to provide an http/ftp pointer to a
single dataset demonstrating the issue if they are public.

Best regards,
Frank

On Mon, Feb 25, 2013 at 11:27 AM, Johannes Landmann  wrote:
>
> Dear GDAL-friends,
>
> I am quite new to GDAL and I've got a substantial question:
>
> For my bachelor thesis I work with EUMETSAT's NDVI data published in HDF5 
> format. These data are "produced" in the geostationary satellite projection 
> but do not contain geospatial reference in the HDF5 dataset.
>
> I have already tried out to assign the projection to the images with  
> "gdalwarp -s_srs SR-ORG:81" as well as "gdalwarp -t_srs SR-ORG:81" but with 
> no result.
>
> What am I doing wrong? Is there another (better) way to "reassign" the 
> projection?
>
> Thanks in advance,
>
> Johannes
> ___
> 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 Software Developer
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Georeference EUMETSAT's NDVI (hdf5)

[Johannes Landmann]

Dear GDAL-friends,

I am quite new to GDAL and I've got a substantial question:

For my bachelor thesis I work with EUMETSAT's NDVI data published in HDF5 
format. These data are "produced" in the geostationary satellite projection but 
do not contain geospatial reference in the HDF5 dataset.

I have already tried out to assign the projection to the images with  "gdalwarp 
-s_srs SR-ORG:81" as well as "gdalwarp -t_srs SR-ORG:81" but with no result.

What am I doing wrong? Is there another (better) way to "reassign" the 
projection?

Thanks in advance,

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

Re: [gdal-dev] ogr2ogr with append fails to convert truncated fields

[Tamas Szekeres]

So we seem to have 3 divergent options to provide a work around:

1. Expose fieldmap setting to let the user decide the order of the fields
to be copied.
2. Modify GetFieldIndex to provide the name based lookup by the truncated
name (for the shape driver specifically)
3. Provide an option to instruct ogr2ogr to consider the source and the
destination has the same field structure (order).

Which would be the most reasonable?

I personally in favour of #3 or #1.  #3 is easier to implement, but #1 is
more customizable.
With regards to #2 we might continue to encounter non trivial matches.

Best regards,

Tamas





2013/2/25 Even Rouault 

> Le lundi 25 février 2013 16:57:08, Tamas Szekeres a écrit :
> > Hi All,
> >
> > Related to issue #3247  we
> > experienced, that if we use ogr2ogr to append source data to a shapefile
> > destination (by using the -append flag) and field name truncation is
> taking
> > place, the corresponding values are not copied.
> >
> > This is because when setting up the field index map (in ogr2ogr) the
> > destination (truncated) field indexes are searched by the name of of the
> > source fields (the long names).
> >
> > Since it's not always trivial to find the correct fields by names, how
> > about exposing the field map itself as an option, something like:
> >
> > ogr2ogr -append -f "ESRI Shapefile" -fieldmap "0,1,2,3,4,5"
> destination.shp
> >  [source]
> >
> >
> > Would that workaround be sufficient?
>
> That would certainly work, although not particularly user friendly, but
> shapefiles are not that user friendly with their various limitations.
>
> Perhaps you could just work with spatialite DBs as intermediate and
> convert to
> shapefile at the end if it is really needed ?
>
> A potential alternative to -fieldmap would be to have :
>
> class OGRLayer:
> {
>public:
>   virtual int GetFieldIndex(const char* pszFieldname);
> }
>
> int OGRLayer::GetFieldIndex(const char* pszFieldname)
> {
> return GetLayerDefn()->GetFieldIndex(pszFieldname);
> }
>
> int OGRShapeLayer::GetFieldIndex(const char* pszFieldname)
> {
> int idx = OGRLayer::GetFieldIndex(pszFieldname);
> if( idx >= 0 )
> return idx;
> /* otherwise implement here truncation logic to find best match */
> /* caution: if there are several potential matches (for example
> verylongcolumnname1 being truncated to verylongna and verylongcolumnname2
> truncated to verylong~1) and you are looking for verylongcolumnXXX then
> return
> -1 */
> }
>
> >
> >
> > Best regards,
> >
> > Tamas
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Suppressing GDAL error output globally/by default in a Java application

[Even Rouault]

Le lundi 25 février 2013 17:11:41, Stefan Moebius a écrit :
> Hi,
> 
> I'm using GDAL (1.7.3) from within JBoss. Having GDAL report errors to
> stderr obviously isn't that helpful in such an environment.
> 
> Now I found that in native code, I could just call CPLSetErrorHandler() to
> get rid of this issue. However, in Java, there only seems to be
> PushErrorHandler(), which is documented as being thread-local.
> 
> How can I suppress error output globally (or by default) from Java?
> Is there an option I could set after initializing GDAL?

I've just added gdal.SetErrorHandler(java.lang.String) for GDAL 1.10 ( see 
http://gdal.org/java/org/gdal/gdal/gdal.html#SetErrorHandler%28java.lang.String%29
 
)

Otherwise on Unix systems, you can define the CPL_LOG environment variable to 
/dev/null (on Windows to NUL) (should also be doable with 
gdal.SetConfigOption("CPL_LOG", "/dev/null") provided you call it very early, 
i.e. before the first GDAL error emitted )

> 
> Regards,
> Stefan
> Actix is the trading name of Actix Limited, with registered offices at:
> 200 Hammersmith Road, London, W6 7DL, United Kingdom.
> Actix Limited is registered in England and Wales with company no.
> 02660615 and VAT no. GB 858742087. Managing Director of Actix Limited: Bill
> McHale.
> 
> Actix GmbH is registered in (Sitz der Gesellschaft): Dresden, Germany with
> company no. Handelsregister Amtsgericht Dresden HR B 19204 and VAT no.
> (Ust-IDNr.) DE 813 115 475. Managing
> Director of Actix GmbH (Geschaeftsfuehrer): Bill McHale.
> 
> Information in this message is confidential and may be legally
> privileged. If you are not the intended recipient, please notify the
> sender, and please delete the message from your system
> immediately.  The statements and opinions expressed in this
> message are those of the author and do not necessarily reflect
> those of Actix.
> 
> Whilst Actix takes every effort to ensure this message is virus
> free it cannot guarantee that this is the case. It is the
> recipient's responsibility to carry out such virus checks as
> it deems necessary
> ___
> 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] Suppressing GDAL error output globally/by default in a Java application

[Stefan Moebius]

Hi,

I'm using GDAL (1.7.3) from within JBoss. Having GDAL report errors to stderr 
obviously isn't that helpful in such an environment.

Now I found that in native code, I could just call CPLSetErrorHandler() to get 
rid of this issue. However, in Java, there only seems to be PushErrorHandler(), 
which is documented as being thread-local.

How can I suppress error output globally (or by default) from Java?
Is there an option I could set after initializing GDAL?

Regards,
Stefan
Actix is the trading name of Actix Limited, with registered offices at: 
200 Hammersmith Road, London, W6 7DL, United Kingdom. 
Actix Limited is registered in England and Wales with company no. 
02660615 and VAT no. GB 858742087. Managing Director of Actix Limited: Bill 
McHale.

Actix GmbH is registered in (Sitz der Gesellschaft): Dresden, Germany with 
company no. Handelsregister Amtsgericht Dresden 
HR B 19204 and VAT no. (Ust-IDNr.) DE 813 115 475. Managing 
Director of Actix GmbH (Geschaeftsfuehrer): Bill McHale. 

Information in this message is confidential and may be legally 
privileged. If you are not the intended recipient, please notify the 
sender, and please delete the message from your system 
immediately.  The statements and opinions expressed in this 
message are those of the author and do not necessarily reflect 
those of Actix. 

Whilst Actix takes every effort to ensure this message is virus 
free it cannot guarantee that this is the case. It is the 
recipient's responsibility to carry out such virus checks as 
it deems necessary
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] ogr2ogr with append fails to convert truncated fields

[Chaitanya kumar CH]

Can we expect the fields to remain in the same order every time?
Hi All,

Related to issue #3247  we
experienced, that if we use ogr2ogr to append source data to a shapefile
destination (by using the -append flag) and field name truncation is taking
place, the corresponding values are not copied.

This is because when setting up the field index map (in ogr2ogr) the
destination (truncated) field indexes are searched by the name of of the
source fields (the long names).

Since it's not always trivial to find the correct fields by names, how
about exposing the field map itself as an option, something like:

ogr2ogr -append -f "ESRI Shapefile" -fieldmap "0,1,2,3,4,5" destination.shp
 [source]


Would that workaround be sufficient?


Best regards,

Tamas


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

Re: [gdal-dev] ogr2ogr with append fails to convert truncated fields

[Even Rouault]

Le lundi 25 février 2013 16:57:08, Tamas Szekeres a écrit :
> Hi All,
> 
> Related to issue #3247  we
> experienced, that if we use ogr2ogr to append source data to a shapefile
> destination (by using the -append flag) and field name truncation is taking
> place, the corresponding values are not copied.
> 
> This is because when setting up the field index map (in ogr2ogr) the
> destination (truncated) field indexes are searched by the name of of the
> source fields (the long names).
> 
> Since it's not always trivial to find the correct fields by names, how
> about exposing the field map itself as an option, something like:
> 
> ogr2ogr -append -f "ESRI Shapefile" -fieldmap "0,1,2,3,4,5" destination.shp
>  [source]
> 
> 
> Would that workaround be sufficient?

That would certainly work, although not particularly user friendly, but 
shapefiles are not that user friendly with their various limitations.

Perhaps you could just work with spatialite DBs as intermediate and convert to 
shapefile at the end if it is really needed ?

A potential alternative to -fieldmap would be to have :

class OGRLayer:
{
   public:
  virtual int GetFieldIndex(const char* pszFieldname);
}

int OGRLayer::GetFieldIndex(const char* pszFieldname)
{
return GetLayerDefn()->GetFieldIndex(pszFieldname);
}

int OGRShapeLayer::GetFieldIndex(const char* pszFieldname)
{
int idx = OGRLayer::GetFieldIndex(pszFieldname);
if( idx >= 0 )
return idx;
/* otherwise implement here truncation logic to find best match */
/* caution: if there are several potential matches (for example 
verylongcolumnname1 being truncated to verylongna and verylongcolumnname2 
truncated to verylong~1) and you are looking for verylongcolumnXXX then return 
-1 */
}

> 
> 
> Best regards,
> 
> Tamas
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] ogr2ogr with append fails to convert truncated fields

[Tamas Szekeres]

Hi All,

Related to issue #3247  we
experienced, that if we use ogr2ogr to append source data to a shapefile
destination (by using the -append flag) and field name truncation is taking
place, the corresponding values are not copied.

This is because when setting up the field index map (in ogr2ogr) the
destination (truncated) field indexes are searched by the name of of the
source fields (the long names).

Since it's not always trivial to find the correct fields by names, how
about exposing the field map itself as an option, something like:

ogr2ogr -append -f "ESRI Shapefile" -fieldmap "0,1,2,3,4,5" destination.shp
 [source]


Would that workaround be sufficient?


Best regards,

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

Re: [gdal-dev] gdalwarp crash

[Simon Lyngby Kokkendorff]

Hi Even,

  Thanks for the pointer - might try again with the -multi option. Anyway,
the -co TILED=YES is speeding things up drastically (something like a
factor 10).

  Cheers,
  Simon


On Mon, Feb 25, 2013 at 1:16 PM, Even Rouault
wrote:

> Le lundi 25 février 2013 11:13:47, Simon Lyngby Kokkendorff a écrit :
> > Hi Even,
> >
> > > When you say "crashed", you mean it exited with the integer overflow
> > > error (to
> > > be opposed as the windows that is displayed by Windows when a process
> > > really
> > > crashes) ?
> >
> >   Yes, it didn't really crash, but exited with the integer overflow error
> > message.
> >
> > The issue is rather with the -wm 3072. The warping algorithm will
> currently
> >
> > > cast a integer overflow error when a memory allocation above 2 GB is
> > > attempted.
> > > So you should try -wm 2047 or less. There's rarely a significant
> > > advantage in
> > > using so big values for -wm.
> >
> > Ahh, I see. I was using win64 and just assumed that setting -vm high
> might
> > speed things up.
>
> See
>
> http://trac.osgeo.org/gdal/wiki/UserDocs/GdalWarp#WillincreasingRAMincreasethespeedofgdalwarp
>
> > Will try to create a tiled output image :-)
> > By the way, I also tried using -multi to speed up (with otherwise the
> same
> > options, I think), but got an error saying something like "Unable to
> aquire
> > IOMutex" (unfortunately I haven't got the exact output).
>
> Hum, this might be a side effect of a particular high value of -wm which
> cause
> particularly big, and consequently long, I/O operations. The mutex
> timeouts at
> 10 minutes currently. Usually unitary I/O operations only last a few
> seconds
> or dozains seconds.
>
> >
> > Thanks,
> > Simon
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] gdaladdo don't seem to work..

[Pietro Rossin]

Hi all
I'll like to add overviews to a 1 bit geotiff

the gdalinfo for this tiff is:
***
Driver: GTiff/GeoTIFF
Files: test.tif
   test.tfw
   test.aux
Size is 292042, 284413
Coordinate System is `'
Origin = (2311161.56486059590,5168752.55830754340)
Pixel Size = (0.426789595821517,-0.426789595819635)
Image Structure Metadata:
  COMPRESSION=CCITTFAX4
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  ( 2311161.565, 5168752.558) 
Lower Left  ( 2311161.565, 5047368.049) 
Upper Right ( 2435802.052, 5168752.558) 
Lower Right ( 2435802.052, 5047368.049) 
Center  ( 2373481.808, 5108060.304) 
Band 1 Block=256x256 Type=Byte, ColorInterp=Palette
  Description = Layer_1
  NoData Value=0
  Metadata:
LAYER_TYPE=athematic
  Image Structure Metadata:
NBITS=1
  Color Table (RGB with 2 entries)
0: 255,255,255,255
1: 0,0,0,255
***
I used:
gdaladdo -r average --config USE_RRD YES test.tif 2 4 8 16

The result is a file called  test.axe 20Gb big and a test.aux file (5Kb)

gdaladdo.exe don't seem to work, in taskmanager it uses 0 to 0.1 cpu%

Gdal 1.9.2 installed with osgeo4w.

By the way, which is the best way to create overviews for this kind of
tiff??

Thankyou
Pietro




--
View this message in context: 
http://osgeo-org.1560.n6.nabble.com/gdaladdo-don-t-seem-to-work-tp5036638.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] gdalwarp crash

[Even Rouault]

Le lundi 25 février 2013 11:13:47, Simon Lyngby Kokkendorff a écrit :
> Hi Even,
> 
> > When you say "crashed", you mean it exited with the integer overflow
> > error (to
> > be opposed as the windows that is displayed by Windows when a process
> > really
> > crashes) ?
> 
>   Yes, it didn't really crash, but exited with the integer overflow error
> message.
> 
> The issue is rather with the -wm 3072. The warping algorithm will currently
> 
> > cast a integer overflow error when a memory allocation above 2 GB is
> > attempted.
> > So you should try -wm 2047 or less. There's rarely a significant
> > advantage in
> > using so big values for -wm.
> 
> Ahh, I see. I was using win64 and just assumed that setting -vm high might
> speed things up.

See 
http://trac.osgeo.org/gdal/wiki/UserDocs/GdalWarp#WillincreasingRAMincreasethespeedofgdalwarp

> Will try to create a tiled output image :-)
> By the way, I also tried using -multi to speed up (with otherwise the same
> options, I think), but got an error saying something like "Unable to aquire
> IOMutex" (unfortunately I haven't got the exact output).

Hum, this might be a side effect of a particular high value of -wm which cause 
particularly big, and consequently long, I/O operations. The mutex timeouts at 
10 minutes currently. Usually unitary I/O operations only last a few seconds 
or dozains seconds.

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

Re: [gdal-dev] Closing disconnected contours

[Chaitanya kumar CH]

zeta,

The gaps are likely caused by pixels with no data. A simple method is to
run gdal_fillnodata.py on the original raster and then create the contours.

http://www.gdal.org/gdal_fillnodata.html



On Mon, Feb 25, 2013 at 1:01 PM, zeta  wrote:

> Hi,
>
> I have shape file from sample map, consisting of topological contours.
> However many contours have small gaps and I'm looking for a pointer how to
> connect those lines, automatically.
> Does ogr have a method or maybe more generally does anyone know of a tool,
> that would correctly close disconnected contours, which aren't labeled?
> Gaps are small - artifacts from graticules present in original image used
> as source for creating this vector.
>
> Thanks
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>



-- 
Best regards,
Chaitanya kumar CH.

+91-9494447584
17.2416N 80.1426E
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] gdalwarp crash

[Simon Lyngby Kokkendorff]

Hi Even,


> When you say "crashed", you mean it exited with the integer overflow error
> (to
> be opposed as the windows that is displayed by Windows when a process
> really
> crashes) ?
>

  Yes, it didn't really crash, but exited with the integer overflow error
message.

The issue is rather with the -wm 3072. The warping algorithm will currently
> cast a integer overflow error when a memory allocation above 2 GB is
> attempted.
> So you should try -wm 2047 or less. There's rarely a significant advantage
> in
> using so big values for -wm.
>

Ahh, I see. I was using win64 and just assumed that setting -vm high might
speed things up. Will try to create a tiled output image :-)
By the way, I also tried using -multi to speed up (with otherwise the same
options, I think), but got an error saying something like "Unable to aquire
IOMutex" (unfortunately I haven't got the exact output).

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

Re: [gdal-dev] gdalwarp crash

[Even Rouault]

Le lundi 25 février 2013 09:35:37, Simon Lyngby Kokkendorff a écrit :
> Hej List,
> 
>   I was using gdal1.10_dev (precompiled from gisinternals.com/sdk) to warp
> a quite large ECW image, but after running for a few days the process
> crashed with an integer overflow error:

When you say "crashed", you mean it exited with the integer overflow error (to 
be opposed as the windows that is displayed by Windows when a process really 
crashes) ?

> 
> C:\Users\simlk\Downloads\release-1600-x64-gdal-mapserver>gdalwarp -s_srs
> "+proj=
> etmerc +ellps=GRS80 +lat_0=0 +lon_0=-39 +k_0= 0.9996 +towgs84=0,0,0,0,0,0,0
> +uni
> ts=m +no_defs" -t_srs "EPSG:4747" -of GTiff -co "BIGTIFF=IF_NEEDED" -ts
> 11 3
> 0 -wm 3072 C:\Ortofoto\GR_samlet_ny.ecw T:\TEMP\simlk\out.tiff
> Creating output file that is 11P x 30L.
> Processing input file C:\Ortofoto\GR_samlet_ny.ecw.
> 0...10...20...30...40...50...60...70...ERROR 1: Integer overflow :
> nDstXSize=275
> 00, nDstYSize=37500
> 
> I was trying to mimic a utm zone 24 projection in my source srs - and yes I
> did forget the false easting +x_0=50, but I doubt the problem is
> related to that.

The issue is rather with the -wm 3072. The warping algorithm will currently 
cast a integer overflow error when a memory allocation above 2 GB is attempted. 
So you should try -wm 2047 or less. There's rarely a significant advantage in 
using so big values for -wm.

> Is there some other creation option that I missed for huge
> output?

You could add -co TILED=YES to produce a tiled geotiff. That might help speed 
up things a bit.

> 
> Cheers,
> Simon Kokkendorff, National Geodata Agency of Denmark
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] gdalwarp crash

[Simon Lyngby Kokkendorff]

Hej List,

  I was using gdal1.10_dev (precompiled from gisinternals.com/sdk) to warp
a quite large ECW image, but after running for a few days the process
crashed with an integer overflow error:

C:\Users\simlk\Downloads\release-1600-x64-gdal-mapserver>gdalwarp -s_srs
"+proj=
etmerc +ellps=GRS80 +lat_0=0 +lon_0=-39 +k_0= 0.9996 +towgs84=0,0,0,0,0,0,0
+uni
ts=m +no_defs" -t_srs "EPSG:4747" -of GTiff -co "BIGTIFF=IF_NEEDED" -ts
11 3
0 -wm 3072 C:\Ortofoto\GR_samlet_ny.ecw T:\TEMP\simlk\out.tiff
Creating output file that is 11P x 30L.
Processing input file C:\Ortofoto\GR_samlet_ny.ecw.
0...10...20...30...40...50...60...70...ERROR 1: Integer overflow :
nDstXSize=275
00, nDstYSize=37500

I was trying to mimic a utm zone 24 projection in my source srs - and yes I
did forget the false easting +x_0=50, but I doubt the problem is
related to that. Is there some other creation option that I missed for huge
output?

Cheers,
Simon Kokkendorff, National Geodata Agency of Denmark
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Closing disconnected contours

[zeta]

Hi,

I have shape file from sample map, consisting of topological contours. However 
many contours have small gaps and I'm looking for a pointer how to connect 
those lines, automatically.
Does ogr have a method or maybe more generally does anyone know of a tool, that 
would correctly close disconnected contours, which aren't labeled?
Gaps are small - artifacts from graticules present in original image used as 
source for creating this vector.

Thanks

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