[gdal-dev] Re-creating mask with nearblack

Hello, I attempted to create a mask with nearblack -alg floodfill -setmask -nb 0 -white file.tif but near 90% it failed because of full disk space. Will re-generating new mask remove (or overwrite) the old one? I wouldn't like my geotiff to contain unused data unfinished mask. If not, is there a

Re: [gdal-dev] Re-post, user-defined

Dear Even, Apologies for taking your time. I couldn’t locate the mentioned error in arcpy. It runs smoothly . I’ve shared the arcpy projection python script and associated data with the link https://u.pcloud.link/publink/show?code=kZj5wh0ZtFWXtI9UGjQiD6KXxn5A9hiWDpEX. If you find a way using gdal

Re: [gdal-dev] Re-post, user-defined

Well the arcpy made transformation before re-projection. Appended the sample script in the shared folder as txt. Anyway how can I achieve this ArcPy output re-projection from gdal with the given gdalinfo on the input file and by editing the PROJ.4 string (target projection )? PARAMETER["Latitude o

Re: [gdal-dev] Re-post, user-defined

At first sight, I'd say that the ArcPy output is incorrect. The SRS definition of its output doesn't match what you want since it has PARAMETER["Latitude of natural origin",20, ANGLEUNIT["degree",0.0174532925199433], ID["EPSG",8801]], PARAMETER["Longitude of natural origin",6378137, ANGLEUNIT["d

Re: [gdal-dev] Re-post, user-defined

Hi Even, thank you for your response, gdal version is: GDAL 3.6.4, released 2023/04/17 I got the defined target projection included in the link. yes, it's geocentric and for further exploration the custom project transformation file .gtf extension is also included. https://u.pcloud.link/publink/sho

Re: [gdal-dev] Re-post, user-defined

Hi, it is difficult to help you with just the elements you've provided. What could be helpful is: - the output of gdalinfo on the input file - the output of gdalinfo on the output file generate by ArcPy - how you define the target projection in ArcPy - the output of gdalinfo on the output fi

[gdal-dev] Re-post, user-defined

Dear all, I am requesting again if you kind have some responds or direction, thank you I have difficulties in accurately reprojecting a raster file to a user-defined projection. I used the following commands in gdal while the output is not similar to arcpy results. kindly offer your guidance to ac

Re: [gdal-dev] Re: Censor area in tiles of aerial image

Hi Frank,I have read about gdal_rasterize but it seems it works a bit different as i need it.Gdal_rasterize converts a vector layer to a raster layer with specific dimensions and create a new file, like a mask.It could be work for me yes, because i publish the raster files as image mosiac at t

[gdal-dev] Re Motion: promote GDAL 3.3.2 RC3

+1 -Jukka Rahkonen- -Alkuperäinen viesti- Lähettäjä: gdal-dev Puolesta Even Rouault Lähetetty: torstai 2. syyskuuta 2021 9.54 Vastaanottaja: gdal-dev@lists.osgeo.org Aihe: [gdal-dev] Motion: promote GDAL 3.3.2 RC3 Hi, Having heard no issues being reported regarding RC3 Motion: Adopt

Re: [gdal-dev] Re help with parsing grc/grd files in python

> In Python , I am using gdal , but Did not find the API’s like the once in R > > > > Do you know any other libraries in Python that are close to rasters library > in R You might want to try Rasterio which uses GDAL underneath: https://rasterio.readthedocs.io/en/latest/ GDAL has also Python bi

[gdal-dev] Re help with parsing grc/grd files in python

Hi I am trying to parse some .grc/.grd/.tab files (mapinfo Gis tool files) and get some data as data-frame and write to Hive One of my colleague wrote this in R He is using rgdal and raster libraries Here is his code to process grc file parse_grc <- function(file_name){ tab_grc <-

[gdal-dev] RE : XLS file can't be opened with gdal 3

Hi Tobias, Yes, gdal is linked against FreeXL 1.0.5 – and reports support for XLS. Note that some other XLS files can be used without problem. This one, which is included in out test suite doesn’t. BR, Fred. Provenance : Courrier pour Windows 10

Re: [gdal-dev] RE : Gdal 2.0, supported raster/vector formats (RIK in particular)

Ok I will remove the files above since they are protected by copyrights (still, I think). Yours Tomas Den 2015-08-21 kl. 23:00, skrev Even Rouault: Tomas, I confirm the issue for RIK v1 and RIK v2 datasets. RIK v3 were fine. I've filed https://trac.osgeo.org/gdal/ticket/6078 and committed a

Re: [gdal-dev] RE : Gdal 2.0, supported raster/vector formats (RIK in particular)

Tomas, I confirm the issue for RIK v1 and RIK v2 datasets. RIK v3 were fine. I've filed https://trac.osgeo.org/gdal/ticket/6078 and committed a fix for trunk and 2.0 branch to restore support for RIK v1 and v2. Even Le jeudi 20 août 2015 20:43:16, TomasR a écrit : > Hi > This made me to try a

Re: [gdal-dev] RE : Gdal 2.0, supported raster/vector formats (RIK in particular)

Hi This made me to try a bit more and found that gdal2 works with some files but not with other files. This small file https://www.dropbox.com/s/5k86qh3g24wrb8r/ab-del.rik?dl=0 gdalinfo.exe can read and give data about. This file https://www.dropbox.com/s/a2dlnvgy5ckxu5b/testkarta.rik?dl=0 whi

[gdal-dev] RE : Gdal 2.0, supported raster/vector formats (RIK in particular)

RIK should be supported in 2.0 as well as in previous versions. could you share a file that no longer work?  --- Spatialys - Geospatial professional services http://www.spatialys.com Message d'origine De : TomasR Date :20/08/2015 11:09 (GMT+01:00) À : gdal-dev@lists.osgeo.

[gdal-dev] ​Re: Raster origin coodinates in file header

Even, Piero, thank you very much for your detailed answers ! Adrien Le 30/06/2015 08:41, Piero Campalani a écrit : Adrien, OGC in its GML standard document -- of course in line with ISO -- recommends that:/ "When a grid point is used to represent a sample space (e.g. image pixel), the grid

[gdal-dev] ​Re: Raster origin coodinates in file header

Adrien, OGC in its GML standard document -- of course in line with ISO -- recommends that: * "When a grid point is used to represent a sample space (e.g. image pixel), the grid point represents the center of the sample space (see ISO 19123:2005, 8.2.2)"*. ​ ​GML encodes the locations of a raster

Re: [gdal-dev] RE Python ogr GetFieldAsString problem

-dev@lists.osgeo.org Objet Re: [gdal-dev] RE Python ogr GetFieldAsString problem Selon steve.tout...@inspq.qc.ca: > Hi Even, > I don't understand why GetFieldAsString() truncates the valueShould it > reads the value as it is? To be pedantic, GetFieldAsString() does no

Re: [gdal-dev] RE Python ogr GetFieldAsString problem

Selon steve.tout...@inspq.qc.ca: > Hi Even, > I don't understand why GetFieldAsString() truncates the valueShould it > reads the value as it is? To be pedantic, GetFieldAsString() does not truncate the value. The value is truncated before, in the GML reader, when inserting the value from the

Re: [gdal-dev] RE Python ogr GetFieldAsString problem

d, CPLAtof(psGMLProperty->papszSubProperties[0]) ); + poOGRFeature->SetField( iDstField, CPLAtofM(psGMLProperty->papszSubProperties[0]) ); } break; > > thanks! > > > > > > > > > Even Rouault > 2015-05-13

Re: [gdal-dev] RE Python ogr GetFieldAsString problem

rator there must be a solution What do you think, Does GetFieldAsDouble should be able to manage the ,''? thanks! Even Rouault 2015-05-13 17:02 A steve.tout...@inspq.qc.ca cc gdal-dev@lists.osgeo.org Objet Re: [gdal-dev] RE Python ogr GetFieldAsString problem Steve,

Re: [gdal-dev] RE Python ogr GetFieldAsString problem

Steve, I believe comma as decimal separator is invalid for a XML double. Hence the GML driver only parses the value up to the comma. This could likely be improved to accept comma, but technically I believe a XML validator would reject this GML. Even > More info. > ogr2ogr --version = GDAL 1.

[gdal-dev] RE Python ogr GetFieldAsString problem

More info. ogr2ogr --version = GDAL 1.10.1, released 2013/08/26 python --version = Python 2.7.3 I have modified my script to get the field type while feat is not None: feat_defn = layer.GetLayerDefn() field_defn = feat_defn.GetFieldDefn(feat_defn.GetFieldIndex(attribut))

[gdal-dev] RE : Re: Call for discusson on RFC 31 - OGR 64bit Integer Fields and FIDs

Dmitriy,  The main reason for the new symbol is that if we change the return type it might cause crashing problems that are not detected at compile time if GetFID is used in a printf like function. For example printf("%ld %s", GetFID (), str) Even --- Spatialys - Geospatial professional servi

Re: [gdal-dev] Re-projecting with valid geometry

klo uo gmail.com> writes: > Thanks Even,that's great solution. > > Now, although ST_IsValid() doesn't report any more problems, QGIS "Check geometry validity" still finds issues on 3 features. > I also tried ArcMap's "Check Geometry" function, and it found 2 "self intersections". Features repor

Re: [gdal-dev] Re-projecting with valid geometry

Thanks Even,that's great solution. Now, although ST_IsValid() doesn't report any more problems, QGIS "Check geometry validity" still finds issues on 3 features. I also tried ArcMap's "Check Geometry" function, and it found 2 "self intersections". Features reported by QGIS and ArcMap are different

Re: [gdal-dev] Re-projecting with valid geometry

Hi, > > Interestingly table reprojected with ogr2ogr shows errors on different > features then errors generated by PostGIS's ST_Transform() function. This is a bit surprising. ogr2ogr applies reprojection on each point of source geometries. I would have expected ST_Transform() to do the same.

[gdal-dev] Re-projecting with valid geometry

Hi, I have PostGIS table with multipolygon geometry column of ~2000 features with valid geometries. Most are single polygons. These were originally in 900914 projection. I tried to re-project to 4326, first with org2ogr then with PostGIS's ST_Transform() function. In both cases I get results wit

[gdal-dev] RE : Re: Reading shapefile PRJ failing

Envoyé depuis un mobile Samsung Message d'origine De : "> Even Rouault (par Internet, dépôt gdal-dev-boun...@lists.osgeo.org)" Date : 12/07/2014 9:29 PM (GMT+01:00) A : Brian McCormick Cc : gdal-dev@lists.osgeo.org Objet : Re: [gdal-dev] Reading shapefile PRJ failing

[gdal-dev] RE : OGR v1.11 CSV GEOM=AS_WKT truncated to 8000 characters (works normally in v1.10.1)

Luc Can you open a ticket about this?  --- Geospatial professional services http://even.rouault.free.fr/services.html Message d'origine De : lucvanlinden Date :03/06/2014 17:45 (GMT+01:00) A : gdal-dev@lists.osgeo.org Objet : [gdal-dev] OGR v1.11 CSV GEOM=AS_WKT truncated

Re: [gdal-dev] RE [Polluriel potentiel] Re: ogr ODBC problem [SOLVED]

Steve, That's good news. I did run into the "spaces" problems on Windows (I had a space between the comma and the table name). It caused the connection to fail. Best Regards, Brent Fraser On 5/31/2012 12:14 PM, steve.tout...@inspq.qc.ca wrote: for ogrinfo we were using, as explained he

[gdal-dev] RE [Polluriel potentiel] Re: ogr ODBC problem [SOLVED]

for ogrinfo we were using, as explained here, http://mapserver.org/input/vector/VirtualSpatialData.html#steps-for-display ogrinfo ODBC:User/Pwd@mssql__archives msStatut_station2002_2006 That was working on windows Though, That doesn't work on our linux distro linux sles 11 sp1. It as to be (comma

Re: [gdal-dev] RE [Polluriel potentiel] Re: ogr ODBC problem

Steve, In my case I was getting OGR to get data from a database view, but it could have been a table. I think OGR needs (would like?) to know which column it can use for unque id. I would expect your view (or table) would have a unique key column otherwise relation operations (like joins)

[gdal-dev] RE [Polluriel potentiel] Re: ogr ODBC problem

Thanks Brent for your answer. But view's primary key? I'm missing something here...What do you mean by that? Do you mean a column with a unique id in the view? There is no such column in my view. Is ogr now needs a unique id in a view? Because it was working before I migrate to linux with a

[gdal-dev] RE ogr ODBC problem

Note that it is a non-spatial mssql database Steve Toutant/INSPQ/ 2012-05-30 16:09 A gdal-dev@lists.osgeo.org cc Objet ogr ODBC problem Hi! I use this command to get the tables from an ODBC connection ogrinfo ODBC:User/Pwd@DNS The connection is succesful but I get this error seve

[gdal-dev] Re: gdal-dev Digest, Vol 96, Issue 55

This is a great listserv! Chaitanya using a vrt worked so thank for that tip. Also, it must be the case as Jukka says that img isn't holding the control points. But as suggested a GeoTiff (and VRT) work fine. Thanks so much for your help. Cheers, Derek On 5/25/2012 7:25 AM, gdal-dev-requ...

[gdal-dev] Re: georeference and project a jpeg

jdmorgan unca.edu> writes: > Hello, I am attempting to georeference and project a jpeg image using only gdal tool. I have georeferenced the jpeg using the following command: gdal_translate -a_srs EPSG:102719 -of HFA -gcp 0.0 0.0 -82.55861878

[gdal-dev] Re: Motion: Promote GDAL 1.9.1RC2 to Final Release

On Thu, May 17, 2012 at 1:36 PM, Frank Warmerdam wrote: > Motion: The GDAL/OGR 1.9.1RC2 release candidate is hearby > declared the final GDAL/OGR 1.9.1 release. Folks, I declare this motion passed with support from Frank, Daniel, Even and Tamas. I'll rename the RC to final and update the news pa

[gdal-dev] Re: Reprojecting a tiled dataset

In case anybody else is trying this, my plan worked out well. I found that doing it via a Python script was the best way, as I added some code to reproject the source extent to destination, calculating the new tiles etc. -- Oyvind On Fri, May 18, 2012 at 10:34 AM, Oyvind Idland wrote: > Hello,

[gdal-dev] Re: Effeciency of "ReadRaster" in different storage format of mulit-band image

My question is when the format of data is BIL or BIP, the efficiency of Band.ReadRaster is quite low. How should I optimize code? I converted one mulit-band image into all the three formats and found that BSQ can read image in the most efficient, the other two is inefficient. So I don't know how c

Re: [gdal-dev] Re: WFS client - missing namespace in filter

Even, my bad, correct.. its ogc, not wfs. -- Oyvind On Wed, May 16, 2012 at 1:25 PM, Even Rouault wrote: > Selon Oyvind Idland : > > > Sorry, forget about that one, it seems to be fixed by now in trunk. > > Actually, this was already fixed in GDAL 1.9. And the namespace used is > xmlns="http://

Re: [gdal-dev] Re: WFS client - missing namespace in filter

Selon Oyvind Idland : > Sorry, forget about that one, it seems to be fixed by now in trunk. Actually, this was already fixed in GDAL 1.9. And the namespace used is xmlns="http://www.opengis.net/ogc"; (not wfs) as recommanded in the WFS 1.1 spec. > > Thanks ! > > -- Oyvind > > On Wed, May 16, 201

[gdal-dev] Re: WFS client - missing namespace in filter

Sorry, forget about that one, it seems to be fixed by now in trunk. Thanks ! -- Oyvind On Wed, May 16, 2012 at 10:10 AM, Oyvind Idland wrote: > Hello, > > there is a minor bug in the filter submitted by WFS GET requests: > > The wfs namespace is missing. The current implementation sends > > htt

Re: [gdal-dev] Re: Scale dependent VRT for overviews

Jukka, I think you could achieve what you want by adding a element (see http://www.gdal.org/gdal_vrttut.html ) inside the element. The dataset pointed by the in can be a .vrt. So, schematically, you would have something like 100_percent.vrt : 50_percent.vrt

Re: [gdal-dev] Re: python SetCacheMax, GetCacheMax

Le lundi 14 mai 2012 19:16:25, Matt Gregory a écrit : > On 5/11/2012 4:55 PM, Gregory, Matthew wrote: > > Hi all, > > > > Probably a newbie question. I'm trying to investigate some read rates without the benefit of caching from Python. When I do this: > >from osgeo import gdal > >gdal.S

[gdal-dev] Re: python SetCacheMax, GetCacheMax

On 5/11/2012 4:55 PM, Gregory, Matthew wrote: Hi all, Probably a newbie question. I'm trying to investigate some read rates without the benefit of caching from Python. When I do this: from osgeo import gdal gdal.SetCacheMax(0) print gdal.GetCacheMax() I always get the environment v

[gdal-dev] Re: Scale dependent VRT for overviews

Hi, I am not sure if it is already possible to do what I want with .VRT file but I just do not know how. Therefore I prepared a test set if someone happens to be interested in having a look. Zip file is at http://latuviitta.org/documents/scale_dependent_gdal_meta_vrt.zip The package contains: -

[gdal-dev] Re: gdal with CMake?

Hi all I've just read the cmake/gdal wiki, the new documentation of the cmake object library and the last "cmake for gdal" discussion from october 2011 and I'm not sure to fully understood why the cmake object library is needed for gdal cmake build. So, I'm wondering if there is some technical d

Re: [gdal-dev] Re: TiffAppendToStrip errors with uncompressed output [SOLVED]

Even Rouault wrote: >> - In case of uncompressed tiff output, make driver to test beforehand if >> there is enough disk space for the target image > I'm not aware of a portable way of doing that (I haven't searched a lot > though). For the record, I've tried the following trick : seek to the offs

Re: [gdal-dev] Re: TiffAppendToStrip errors with uncompressed output [SOLVED]

Le mercredi 09 mai 2012 12:13:06, Jukka Rahkonen a écrit : > Ahem, > > It seems to be so that compression makes resulting tiff files smaller. In > some cases they can then fit to almost full disk even there is not enough > room for an uncompressed version. > > An explanation for why I did not no

[gdal-dev] Re: How to create a fake GeoTIFF for GeoJP2

Frank Warmerdam pobox.com> writes: > > > > gdal_translate -srswin 0 0 1 1 original.tif to_be_embedded.tif? > > > > This is the gdalinfo from a geotiff that I took out from the UUID box of a > > GeoJP2 image. It seems to be exactly just the topleft pixel of the image. > > Jukka, > > Yes, this s

RE: [gdal-dev] Re: gdal_translate waits at the end of operation

Frank Warmerdam Sent: Thursday, May 10, 2012 11:17 AM To: kaari...@gmail.com Cc: gdal-dev@lists.osgeo.org Subject: Re: [gdal-dev] Re: gdal_translate waits at the end of operation On Thu, May 10, 2012 at 9:59 AM, Karu Kaarigar wrote: > Thanks, Frank. I am not familiar with the gdal development at

Re: [gdal-dev] Re: gdal_translate waits at the end of operation

On Thu, May 10, 2012 at 9:59 AM, Karu Kaarigar wrote: > Thanks, Frank. I am not familiar with the gdal development at all. But I > think replacing the driver binary with this new one wit your change should > fix the behavior locally for me? > > Kaarigar > Kaarigar, The XYZ driver is

Re: [gdal-dev] Re: gdal_translate waits at the end of operation

Thanks, Frank. I am not familiar with the gdal development at all. But I think replacing the driver binary with this new one wit your change should fix the behavior locally for me? Kaarigar On Thu, May 10, 2012 at 9:32 AM, Frank Warmerdam wrote: > OK, I have reworked the xyz driver

Re: [gdal-dev] Re: gdal_translate waits at the end of operation

OK, I have reworked the xyz driver a bit. The change is at: http://trac.osgeo.org/gdal/changeset/24402 It should be possible to retrofit the driver into older version. Code at: http://svn.osgeo.org/gdal/trunk/gdal/frmts/xyz/xyzdataset.cpp Best regards, On Thu, May 10, 2012 at 9:06 AM, Fr

Re: [gdal-dev] Re: gdal_translate waits at the end of operation

Ah, I see I misunderstood what Even's change was doing. I'll work on this. On Thu, May 10, 2012 at 8:56 AM, Frank Warmerdam wrote: > Folks, > > I have discovered Even already implemented my idea for XYZ and AAIGRID > 19 months ago.  Based on that I don't know why you are seeing a large > wait o

Re: [gdal-dev] Re: gdal_translate waits at the end of operation

Folks, I have discovered Even already implemented my idea for XYZ and AAIGRID 19 months ago. Based on that I don't know why you are seeing a large wait on closing. http://trac.osgeo.org/gdal/changeset/20770/trunk/gdal/frmts/xyz hmm, I see a reference to 1.9dev - perhaps that was an old 1.9 pr

Re: [gdal-dev] Re: gdal_translate waits at the end of operation

It should be possible to specially implement the CreateCopy for XYZ format to avoid this. I'll investigate this. Best regards, On Thu, May 10, 2012 at 8:30 AM, kaarigar wrote: > > Etienne Tourigny-3 wrote >> >> Something that is not apparent is that gdal_translate (via driver's >> GDALCreateCo

[gdal-dev] Re: gdal_translate waits at the end of operation

Etienne Tourigny-3 wrote > > Something that is not apparent is that gdal_translate (via driver's > GDALCreateCopy()) usually opens the new dataset after creation, and > the XYZ file loading is slow: > That explains it - the XYZ file created is ~4gb in size - it would take it a very very long tim

Re: [gdal-dev] Re: gdal_translate waits at the end of operation

On Thu, May 10, 2012 at 3:16 AM, kaarigar wrote: > Thanks for the suggestion. I tried to convert GeoTIFF to jpg - and there > wasn't the problem. Then I tried to convert a small GeoTIFF (20 mb) to XYZ - > it still waited for some time (~10 secs) after displaying the "Done." > message. I think what

Re: [gdal-dev] Re: Disk or database full error from Rasterlite driver

On Thu, 10 May 2012 06:49:07 + (UTC), Jukka Rahkonen wrote: Is there a way for me as a non-programmer to check if the components used for Rasterlite conversion in the Windows 32-bit binaries from gisinternals.com have been built with or without -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE=1

[gdal-dev] Re: Disk or database full error from Rasterlite driver

lqt.it> writes: > > On Wed, 9 May 2012 19:50:15 + (UTC), Jukka Rahkonen wrote: > > However, the Rasterlite file size has probably been > > around 4 gigabytes when the error occurred. Did I meet some file size > > limit or tile count limit of the Rasterlite driver? > > > > Hi Jukka, > > on

[gdal-dev] Re: gdal_translate waits at the end of operation

Thanks for the suggestion. I tried to convert GeoTIFF to jpg - and there wasn't the problem. Then I tried to convert a small GeoTIFF (20 mb) to XYZ - it still waited for some time (~10 secs) after displaying the "Done." message. I think what is happening is that I was converting a set of very large

Re: [gdal-dev] Re: gdal_translate waits at the end of operation

Kaarigar is using gdal_translate on Windows 7 64 bit from Geoinformatica stack, which I've compiled with MingW/MSYS on Windows 7 32 bit. I just tried similar command line on Windows Server 2008 R2 64 bit and I don't see it stalling after conversion. Best regards, Ari On 05/10/2012 02:34 AM,

Re: [gdal-dev] Re: gdal_translate waits at the end of operation

do you get the same problem when converting to another format (say gtiff) or using other files as input? Etienne On Wed, May 9, 2012 at 9:17 PM, kaarigar wrote: > I can convert a single image to XYZ from command line. And can also convert > multiple images to command line via batch file - if I p

[gdal-dev] Re: gdal_translate waits at the end of operation

I can convert a single image to XYZ from command line. And can also convert multiple images to command line via batch file - if I press CTRL-C after the conversion for one file is 100% done - it will continue to the next file. There are no errors or warnings. The conversion to XYZ is successful. I

Re: [gdal-dev] Re: gdal_translate waits at the end of operation

More questions? Can you convert one image into an xyz? It sounds like you can. Are there no errors or warnings? On Wed, May 9, 2012 at 5:34 PM, kaarigar wrote: > Here's the command line: > > gdal_translate -ot Float32 -of XYZ -co "COLUMN_SEPARATOR=," n40w124.tif > n40w124.xyz > > > Kyle Shann

[gdal-dev] Re: gdal_translate waits at the end of operation

Here's the command line: gdal_translate -ot Float32 -of XYZ -co "COLUMN_SEPARATOR=," n40w124.tif n40w124.xyz Kyle Shannon-3 wrote > > Sounds like your doing something wrong, it shouldn't hang. Can you share > your command line args or a snippet of your batch file? > > kss > -- View this me

[gdal-dev] Re: TiffAppendToStrip errors with uncompressed output [SOLVED]

Ahem, It seems to be so that compression makes resulting tiff files smaller. In some cases they can then fit to almost full disk even there is not enough room for an uncompressed version. An explanation for why I did not notice that disk was too full was that the LZW compression is so effective

Re: [gdal-dev] Re: TiffAppendToStrip errors with uncompressed output

Jukka I downloaded and converted your test VRT file to a single Geotiff without any problems - on Linux... Conversion took a few minutes on a fast server. Just a guess, but in my opinion this problem is related to the limited memory handling capabilities of Windows. It does not seem to be a

[gdal-dev] Re: TiffAppendToStrip errors with uncompressed output

Jukka Rahkonen mmmtike.fi> writes: > > Hi, > > I have some LZW compressed paletted 8-bit tiff files which I look through a .vrt > file. I have been taking some timings with different gdal_translate parameters > but for some reason the most common command fails always for me. The result is >

Re: [gdal-dev] Re: MrSID driver, JPEG2000 format files and world files

Including the patch, the driver tries to find .sdw, .sidw, .wld, and .j2w files if no geotransform is found in the base file. On Thu, May 3, 2012 at 1:43 AM, Jukka Rahkonen wrote: > the Old Topo Depot novacell.com> writes: > > > > > > > Ticket http://trac.osgeo.org/gdal/ticket/4651 opened with

[gdal-dev] Re: MrSID driver, JPEG2000 format files and world files

the Old Topo Depot novacell.com> writes: > > > Ticket http://trac.osgeo.org/gdal/ticket/4651 opened with patch file attached. > Because it is a GDAL driver it might be good to find also .wld world files if it does not find them yet. -Jukka Rahkonen- _

[gdal-dev] Re: OFTReal values truncated to integer

Uh, ok, I forgot to add () after the variable name: CPLLocaleC oLocaleCForcer(); For future readers, I also specify that this declaration must be placed *after* the "OGRRegisterAll();" line to take effect. For completeness, does anyone know how to do the same hack in Python code? Thank you all,

[gdal-dev] Re: OFTReal values truncated to integer

If I include "gdal/cpl_conv.h", code completition works, but I get a compilation error: undefined reference to `CPLLocaleC::CPLLocaleC()' I searched in the source files of my GDAL library version (1.7.0) and the CPLLocaleC class definition exists. I'm sorry for asking again you help! My compilat

Re: [gdal-dev] Re: OFTReal values truncated to integer

> *Now, Python and CodeLite code work fine, and produce the value 1.3 for the > Elev field, Qt Creator code don't and the saved value is read as 1 (because > is codified as "1,3" and not as "1.3")!!!* > > Now, I took a look inside the source code of the GDAL library. > The method that writes real

Re: [gdal-dev] Re: OFTReal values truncated to integer

diegogb, I too got a similar error, but with python code. I am working on a patch for this. On Sat, Apr 28, 2012 at 10:46 PM, diegogb wrote: > Ok, I executed many tests and I found something strange. > I tried: > > - QT Creator, > - CodeLite, > - Python > > I wrote the following programs; > > /

[gdal-dev] Re: OFTReal values truncated to integer

Ok, I executed many tests and I found something strange. I tried: - QT Creator, - CodeLite, - Python I wrote the following programs; // C++ CodeLite version. #include "gdal/ogrsf_frmts.h" int main(int argc, char *argv[]) { OGRRegisterAll(); OGRSFDriver *driver = OGRSFDriverRegistrar::Ge

[gdal-dev] Re: OFTReal values truncated to integer

In addiction to what I previously wrote, I noticed that the problem does not affect the x and y coordinates of the point. I'm using the last version of the Linux Mint OS. -- View this message in context: http://osgeo-org.1560.n6.nabble.com/OFTReal-values-truncated-to-integer-tp4933952p4935441.htm

[gdal-dev] Re: OFTReal values truncated to integer

When I open the dbf file with LibreOffice Calc, the value of the Elev field is 1. *If I open the same file with GHex, the value, represented in ASCII, is "1,3"*, so I think that you're right and GDAL uses my local settings and writes reals using the comma to separate the decimal digits from the int

[gdal-dev] Re: geoTiff to tiles

len lee gmail.com> writes: > > I am working with 2gb large geotiff image.I need convert the large geoTiff to tiles (about 250x250 pixels) with c++ language;i dont wanna read the whole geotiff file since it is gonna be real slow .. i want to get the tiles according to geographic position and i a

Re: [gdal-dev] Re: Request to Visual Studio 2008+ users

Le dimanche 22 avril 2012 15:23:41, Mateusz Loskot a écrit : > On 22 April 2012 14:19, Even Rouault wrote: > > Le dimanche 22 avril 2012 14:20:50, Mateusz Loskot a écrit : > >> On 22 April 2012 13:19, Mateusz Loskot wrote: > >> > 3) nmake /f makefile.vc MSVC_VER= DEBUG-1 > >> > >> Correction

Re: [gdal-dev] Re: Request to Visual Studio 2008+ users

On 22 April 2012 14:19, Even Rouault wrote: > Le dimanche 22 avril 2012 14:20:50, Mateusz Loskot a écrit : >> On 22 April 2012 13:19, Mateusz Loskot wrote: >> > 3) nmake /f makefile.vc MSVC_VER= DEBUG-1 >> >> Correction, s/-/=/ so the command reads >> >> nmake /f makefile.vc MSVC_VER= DEB

Re: [gdal-dev] Re: Request to Visual Studio 2008+ users

Le dimanche 22 avril 2012 14:20:50, Mateusz Loskot a écrit : > On 22 April 2012 13:19, Mateusz Loskot wrote: > > 3) nmake /f makefile.vc MSVC_VER= DEBUG-1 > > Correction, s/-/=/ so the command reads > > nmake /f makefile.vc MSVC_VER= DEBUG=1 I just did your scenario with VS 2008 Express

[gdal-dev] Re: Request to Visual Studio 2008+ users

On 22 April 2012 13:19, Mateusz Loskot wrote: > > 3) nmake /f makefile.vc MSVC_VER= DEBUG-1 Correction, s/-/=/ so the command reads nmake /f makefile.vc MSVC_VER= DEBUG=1 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net ___ gdal-dev

Re: [gdal-dev] Re: Performance of reading large polygons with holes

> Hi, > > Ok, this is interesting for several reasons : > > 1) Trying to run the 'ogrinfo -sql "select max(OGR_GEOM_AREA) from tpi_1" > tpi_1.shp' showed that a badly written optimization in OGR 1.9.0 broke such > a query. Now fixed per http://trac.osgeo.org/gdal/ticket/4633 > > 2) Width GDAL tr

Re: [gdal-dev] Re: Performance of reading large polygons with holes

Le dimanche 22 avril 2012 10:53:22, Jukka Rahkonen a écrit : > Rahkonen Jukka mmmtike.fi> writes: > > Thus it is 4 seconds vs. 32 seconds measured by Martin. It is a > > considerable > > difference but perhaps Martin is > > > not doing exactly the same thing. Anyway, speed of OGR seems to be >

[gdal-dev] Re: Performance of reading large polygons with holes

Rahkonen Jukka mmmtike.fi> writes: > Thus it is 4 seconds vs. 32 seconds measured by Martin. It is a considerable difference but perhaps Martin is > not doing exactly the same thing. Anyway, speed of OGR seems to be excellent. I am acting as a man-in-a-middle and Martin writes now as follows:

[gdal-dev] Re: MSSQL Spatial and 3D issue

Ticket created: http://trac.osgeo.org/gdal/ticket/4626 -- View this message in context: http://osgeo-org.1560.n6.nabble.com/gdal-dev-MSSQL-Spatial-and-3D-issue-tp4892552p4896281.html Sent from the GDAL - Dev mailing list archive at Nabble.com. ___ gdal

Re: [gdal-dev] Re: Adding GMLJP2 metadata into existing JPEG2000 file

Le vendredi 13 avril 2012 15:30:44, Jukka Rahkonen a écrit : > Even Rouault mines-paris.org> writes: > > Jukka, > > > > Your question made me look more closely at the capabilities of the JP2Box > > support in GDAL, and I discovered that I had to write just a few lines of > > code to add support f

[gdal-dev] Re: Adding GMLJP2 metadata into existing JPEG2000 file

Even Rouault mines-paris.org> writes: > > Jukka, > > Your question made me look more closely at the capabilities of the JP2Box > support in GDAL, and I discovered that I had to write just a few lines of > code > to add support for writing georeferencing in the existing openjpeg driver. > S

[gdal-dev] Re: gdal_translate custom binary image format

Hi folks, thank you for you hints! It is working and I am waiting for the gdal2tiles script to build my 25GB quadtree. :-) Cheers, David -- View this message in context: http://osgeo-org.1560.n6.nabble.com/gdal-translate-custom-binary-image-format-tp4851982p4854974.html Sent from the GDAL - Dev

[gdal-dev] Re: python downsample API?

On 2012-04-11 19:17:27 +, David Shean said: Michael, Scott is right.  Not sure if this is the preferred approach, but I accomplished this for large datasets by specifying buffer sizes for ReadAsArray.  The doc I consulted is here: http://gdal.org/python/osgeo.gdal_array-module.html#BandRe

[gdal-dev] Re: Are unicode field values supported in the Python bindings for GDAL?

I submitted a ticket to address this issue. http://trac.osgeo.org/gdal/ticket/4608 RHH """ Currently, using the Python SWIG bindings for GDAL 1.9.0, feature.SetField(0, u'xxx') feature.SetField(0, 'Спасибо'.decode('utf-8')) raise the following exception NotImplementedError: Wrong numb

[gdal-dev] Re: Slow writing into Spatialite with -skipfailures

Jukka Rahkonen mmmtike.fi> writes: > I managed to trap one problematic case but there is something weird > going on. The feature comes originally from Oracle and it is for sure > a polygon there (GTYPE=2003). I have converted it into shapefile with > GDAL 1.6 and OCI plugin from OSGeo4W becau

[gdal-dev] Re: Slow writing into Spatialite with -skipfailures

Even Rouault mines-paris.org> writes: > Hum, would be interesting to have a sample to examine one of the geometry that > triggers the error. The SRID hypothesis seems unlikely, and as far as the > geometry type is concerned, it is weird because you have specified -nlt > MULTIPOLYGON ... >

Re: [gdal-dev] Re: Slow writing into Spatialite with -skipfailures

> > What is the error reported when inserting features into the Spatialite DB > > that makes the use of -skipfailures necessary ? > > The error is this one: > ERROR 1: sqlite3_step() failed: > parcel.GEOMETRY violates Geometry constraint [geom-type or SRID not > allowed] ( 19) Hum, would be in

[gdal-dev] Re: Slow writing into Spatialite with -skipfailures

Jukka Rahkonen mmmtike.fi> writes: > The error is this one: > ERROR 1: sqlite3_step() failed: > parcel.GEOMETRY violates Geometry constraint [geom-type or SRID not allowed] ( > 19) > > Ogr2ogr managed to insert only 273886 polygons in 13 hours into spatialite db so > I canceled the job inst

[gdal-dev] Re: Slow writing into Spatialite with -skipfailures

Even Rouault mines-paris.org> writes: > > Le mercredi 04 avril 2012 19:16:34, Rahkonen Jukka a écrit : > > Even Rouault wrote: > > >Selon Jukka Rahkonen mmmtike.fi>: > > >> Hi, > > >> > > >> I had to write a million polygon shapefile into Spatialite with > > >> -skipfailures and I noticed that

  1   2   3   4   5   6   7   8   9   10   >