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

cheesybiscuits gmail.com> writes: > > I don't see a donate option on the GDAL site but as this is an excellent > tool set with great support I'd be happy to contribute. GDAL is a OSGeo project and in http://www.osgeo.org/ you can see such a button. It does not seem to have an option to select

Re: [gdal-dev] gdalwarp produces all black output

gdalinfo -mm shows your input data file has all it's values in the range 518 to 2396. When converted to a 16bit tif, these all fall in a range that appears black on your screen. You need to rescale the data to fill the 16bit range. This is easily done with gdal_translate, which is probably what

Re: [gdal-dev] 64bit integers

Hi Brent, It's in PostgreSQL. We could convert the field to a string data type, but that's not the point. OGR is currently corrupting data without telling the user! Cheers Jeremy From: pcr...@pcreso.com [mailto:pcr...@pcreso.com] Sent: Thursday, 29 November 2012

[gdal-dev] gdalwarp produces all black output

Newbie question here. I am trying to convert a DTED1 image to GeoTiff. The below command gives me a mosaic.tif image that is totally black. gdalwarp -ot Int16 n29.dt1 mosaic.tif Here is a link to my source image: https://www.dropbox.com/s/zjnbshnwmu67o3o/n29.dt1 Any advice is greatly appreciat

Re: [gdal-dev] 64bit integers

Hi Jeremy, Outside of a GDAL solution, what format is the underlying data stored in? I have resolved issues like this with Postgis data stores by doing the int64 to string conversion in the query generating the data for the service, or via views on the source tables. Not the most elegant approach

Re: [gdal-dev] Character Encoding Problem

HI, I have found the cause of the problem. The field of interest in Oracle is defined as NVARCHAR2. It seems that GDAL cannot deal with this data type properly. See http://docs.oracle.com/cd/B19306_01/server.102/b14220/datatype.htm#i14946 from the Oracle documentation regarding the NVARCHAR2 d

[gdal-dev] Character Encoding Problem

Hi All, I have a problem with a character encoding problem. It could be a UTF-16 to UTF-8 problem or some other encoding problem. I have an SDE Server with the DB being Oracle from which I am extracting an ESRI Shapefile. Using ogr2ogr from GDAL to extract the shapefile I am losing every secon

Re: [gdal-dev] Georeference vector data with OGR

On 29 11 2012 at 12:07 AM, "Even Rouault" wrote: >If you use GDAL trunk (latest revision r25263 from a few minutes >ago that will >be reflected in the -development packages of >http://www.gisinternals.com/sdk/ >in a few hours), a -gcp option has been added to ogr2ogr. See >http://trac.osgeo.or

Re: [gdal-dev] Georeference vector data with OGR

Le mercredi 28 novembre 2012 20:33:47, deb a écrit : > Hi, > > I asked this question on stackexchange: > http://gis.stackexchange.com/questions/42421/dxf-to-georeferenced-shp but > did not receive acceptable answer. I also visited irc channel, but there > is no activity. > > So I thought to join

Re: [gdal-dev] Cannot read UTM Ozi .map file

Hi Jean-Claude, After applying the suggested patch, it no longer errors out in the same way, however, I now get another error just a little further on in my code. CODE: - char *srcWKT = (char *)GDALGetProjectionRef( hDataset ); if ( srcWKT

[gdal-dev] 64bit integers

I have a WFS layer with a 64bit integer field (sufi): http://wfs.data.linz.govt.nz/83de09e2215a4d0c914dbfe28bb71557/v/x1208/wfs?service=WFS When using ogr this 64bit integer field gets truncated to 32bit without any warning. E.g ogrinfo -al 'wfs:http://wfs.data.linz.govt.nz/83de09e2215a4d0c914

[gdal-dev] Georeference vector data with OGR

Hi, I asked this question on stackexchange: http://gis.stackexchange.com/questions/42421/dxf-to-georeferenced-shp but did not receive acceptable answer. I also visited irc channel, but there is no activity. So I thought to join this mailing list and ask my question. Sounds desperate, right? We

Re: [gdal-dev] WFS DefaultSRS OtherSRS

> How the wfs driver handles the OtherSRS ? > Is he handles only the DefaultSRS ? It will select the DefaultSRS, unless you add as an option like &SRSNAME=urn:ogc:def:crs:EPSG:6.9:4326 to the WFS connexion string. > berst regards > xavier ___ gdal-de

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

Haha amazing! Thanks for your input Tamas. I had all the relevant Oracle and FileGDB pieces installed, and correctly in the path. I just needed to copy ogr_FileGDB.dll from bin\gdal\plugins-external to bin\gdal\plugins and I'm in business. Thanks all for the assistance, especially when it was a m

Re: [gdal-dev] CRS not defined with BMP

As far as I know, bmp files (like jpeg and gif and probably others) only support "ESRI World files". This is not a true CRS definition though, it only indicated the geotransform. Even though it is not standard, it would be convenient to update these drivers to read an associated .prj file http:/

Re: [gdal-dev] Cannot read UTM Ozi .map file

Le 28/11/2012 05:16, Nik Sands a écrit : Hi GDAL-dev, I've recently re-compiled GDAL from the trunk after the patch to fix UTM ozi files was applied. This has worked well for most UTM files I've tried so far, but I've come across one that produces a strange error in my code, but works OK with

[gdal-dev] WFS DefaultSRS OtherSRS

Hi The capability of a WFS source return something like this : - WPI_Aug09 urn:ogc:def:crs:EPSG:6.9:104000 urn:ogc:def:crs:EPSG:6.9:4326 - text/xml; subType=gml/3.1.1/profiles/gmlsf/1.0.0/0 - -178.13299717 -77.849998775 179.36699705 78.916697912

Re: [gdal-dev] Space in PDF option OGR_DISPLAY_LAYER_NAMES

> I apologize and try to be more explicit in the future. No pb. In an ideal world, the regression would have been catched by the automated regression tests, but as it only showed in Acrobat and not with poppler rendering, this is not really doable. > I repeated the test with r25261 and layer nam

Re: [gdal-dev] Space in PDF option OGR_DISPLAY_LAYER_NAMES

Even Rouault wrote: > > Le mardi 27 novembre 2012 09:28:06, Jukka Rahkonen a écrit : > > Even Rouault mines-paris.org> writes: > > > There was indeed something wrong in the way the layer name was > > > written for the model tree, which caused invalid PDF structure to be > > > generated when there

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

GDAL plugins should either be installed into a /gdalplugins subdirectory from where the executable is running or set GDAL_DRIVER_PATH to point to the directory containing these files. With regards to gisinternalsboth the oracle and the filegdb plugins are provided,