[gdal-dev] Removing GCPs from tiff
Hi all I've got a tiff file with a number of stored GCPs. How can I remove these GCPs from the file? I've tried: SetGCPshttp://www.gdal.org/classGDALDataset.html#3c812b05467213f05055c1f18438d874(int nGCPCount, const GDAL_GCP http://www.gdal.org/structGDAL__GCP.html*pasGCPList, const char *pszGCPProjection) with the first parameter of 0, but without luck. Seems like SetGCPs only adds the GCPs, rather than re-assigns the entire stored set. Chris ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] About the legality of import - export
What are your experience about this topic? For example, we have dwg, shp, pdf files : Can I distribute a program that import an export data in these formats ? And what about writing data into an existing files ? What legal implications we have to be in mind? Thanks ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Re: Removing GCPs from tiff
Goo Creations goocreations at gmail.com writes: Hi allI've got a tiff file with a number of stored GCPs. How can I remove these GCPs from the file?I've tried: SetGCPs(int nGCPCount, const GDAL_GCP *pasGCPList, const char *pszGCPProjection)with the first parameter of 0, but without luck. Seems like SetGCPs only adds the GCPs, rather than re-assigns the entire stored set.Chris If you just want to do the job, use gdal_translate and write a new tiff file by using -co PROFILE=BASELINE. If you want to program I can't unfortunately help. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Problems in building java bindings
Hello I need to build GDAL in java. I already followed the steps mentioned in http://trac.osgeo.org/gdal/wiki/GdalOgrInJavaBuildInstructions I am successful till compiling GDAL but I am stuck from the next step --Build java bindings Please guide me how to proceed further.what are the steps I need to follow(what all settings are required?what does this line mean use nmake/cl.exe to build the C++ side of the Java bindings and ANT/javac) Do I need to set these files(gdal.jar, gdalconstjni.dll, gdaljni.dll, ogrjni.dll and osrjni.dll.) prior to generation of java bindings or these'll get created after I run nmake /f makefile.vc java automatically. can anyone please elaborate the steps from Build java bindings onwards(That'll be truely helpful. Kindly reply back soon as I am not able to move ahead. Thanks Regards Natasha___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] About the legality of import - export
On 11-04-12 03:26 AM, Antonio P. wrote: What are your experience about this topic? For example, we have dwg, shp, pdf files : Can I distribute a program that import an export data in these formats ? And what about writing data into an existing files ? What legal implications we have to be in mind? Thanks Antionio, There are no legal issues with reading and writing shapefiles. The format is public and GDAL/OGR does not use any code with unusual licensing for this format. For PDF I am guessing you are using the Poppler based PDF driver in GDAL. If you build with Poppler you should review it's licensing information which is, I believe, GPL. So if you distribute a program using GDAL/OGR and Poppler there are legal ramifications for your program. Essentially you would need to provide source code for the program linked with GDAL. For DWG, I'm not sure what you are planning on. GDAL/OGR does not currently read DWG. There is some discussion of a DWG reader based on the Open Design Alliance libraries. If that comes to fruition there will be special legal issues due to their proprietary licensing. Note that the above addresses responsibility for software distribution. For any given file there may be other restrictions on it from the creator or distributor of the data. I can't address that here. But generally ensuring those requirements are followed will be the responsibility of whoever accepts the data - not the software distributor. 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] Removing GCPs from tiff
On 11-04-12 03:17 AM, Goo Creations wrote: Hi all I've got a tiff file with a number of stored GCPs. How can I remove these GCPs from the file? I've tried: SetGCPs http://www.gdal.org/classGDALDataset.html#3c812b05467213f05055c1f18438d874(int nGCPCount, const GDAL_GCP http://www.gdal.org/structGDAL__GCP.html *pasGCPList, const char *pszGCPProjection) with the first parameter of 0, but without luck. Seems like SetGCPs only adds the GCPs, rather than re-assigns the entire stored set. Chris, Jukka's suggestion is good. I would also encourage you to file a ticket on this. Calling SetGCPs() with zero GCPs *ought* to clear them. 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
[gdal-dev] Re: OGR/Spatialite patches
Hi Alessandro, (CC'ing gdal-dev) Impressive work ! My remarks and questions: 1) Could you confirm that all this work might be included under the usual GDAL X/MIT licence ? Due to the significant code addition for the 3D geometry support, you might want to add your copyright in the header of ogrsqlitelayer.cpp. 2) It would be really convenient to have different patches for the different issues that could be applied sequentially. Applying all this stuff in a single gulp will make bisection and analysis of the changes quite painfull. I've skimmed quickly through the whole diff and your README and I can see several patches, preferably in the following order (if possible) : 1) 3D geometry support 2) use the spatialite SQL functions and drop the manual workarounds to avoid using spatialite functions 3) general cleanup to remove the use of ancient sqlite API (that seem not to be directly related to spatialite support) I'd be in favor of dropping the stuff related to #ifdef SPATIALITE_AMALGAMATION for now. Or it might be traced under a different ticket 3) From your patch I can see that my efforts to produce a spatialite database without linking to spatialite were vain. I'm not that surprised however So the question is : is there really an interest in allowing the user to create a spatialite database without linking to spatialite if that database cannot be directly used by other spatialite-enabled software ant that the user must repair it afterwards with the procedure at the end of your README.txt. This really sounds to be compatible with only super power users... We might also want to be sure that no write/update/delete operations can happen to a spatialite database if it is opened with a driver not linked against libspatialite to avoid corrupting it. However I think it is still desirable to be able to read a spatialite database without requiring linking to spatialite. 4) We must be aware that using the ALTER TABLE ... ADD COLUMN ... stuff will produce databases (even regular SQLite ones) that will not be compatible with the latest FWTools for Windows that uses an ancient sqlite versions. Might not be a big deal however because I somehow remember that dropping a new version of sqlite3.dll in the bin directory make it work again. 5) Would you be willing to update/extend the autotest/ogr/ogr_sqlite.py test to ensure that it still passes and add some tests for all the new stuff, particularly the 3D geometry support. 6) From your README.TXT, can I assume that your changes have been tested against regular libsqlite3 (without linking to spatialite) with a spatialite database (and also a regular sqlite database not using spatialite geometries), and against libspatialite 2.3.1 and libspatialite 2.4.0 for spatialite databases ? 7) A minor code note : it could be interesting to replace the magic values for the geometry types by appropriate #define with symbolic names. 8) I've seen you have removed the tests to detect int overflows, for example if( nPointCount 0 || nPointCount INT_MAX / (2 * 8)) has become if( nPointCount 0). Could you justify it ? I still think that they are necessary to avoid issues in lines below if the nPointCount value is huge enough. 9) About your [3c] patch. Yes indeed this is a painfull issue with shapefiles (the format I mean, not the driver) where we cannot know in advance if it only contains LINESTRING or MULTILINESTRING. Currently the shapefile driver chooses to report the layer as having LINESTRING geometry type. Maybe Frank can comment about this. I imagine this was decided because some application software wouldn't know to deal with multi-geometry. But I can confirm that inserting such shapefiles with mixed linestring/multilinestring geometries into Postgis requires a -nlt flag to the ogr2ogr command line. To get back to your patch, I'm wondering what will happen if we try to insert a feature with a LINESTRING geometry into a layer created with the LINESTRING geometry type, that has been promoted to MULTILINESTRING by the driver ? Best regards, Even Le mercredi 30 mars 2011 12:37:05, Alessandro Furieri a écrit : Hi All, I know for sure that all you are strongly interested in both SpatiaLite and GDAL/OGR: so I'm glad to submit to your attention a patch-set intended to enhance the OGR/spatialite driver. - correcting several issues found into the current implementation - supporting the most recent features introduced by v.2.4.0 [3D Geometries and so on] You'll find everything within the attached zipfile: - source code - svn diff - detailed explanations on README.txt Please note: the current patch-set (although quite thoroughly tested and debugged by myself) simply represents a preliminary interim version. I suppose some further (small)
Re: Fwd: [gdal-dev] problem with decimal precision (SAGA driver)
Selon Volker Wichmann wichm...@laserdata.at: Well, is this really a problem... ? I mean 12181.2999 = 12181.3 for most purposes. Sometimes you can have different decimal representations for the same IEEE number... I'm not sure this is really something adressed in GDAL drivers. But if you are really annoyed with this, you could look at OGRFormatDouble() (ogr/ogrutils.cpp) that has some ugly and fragile (needed tweaking because MSVC or GCC don't behave the same when printing a floating point number) logic to detect and remove trailing 99x or 00x. It is used when outputting coordinates into WKT, GML or KML. Hi Even, since you helped so much to implement the SAGA driver, I'm writing to you directly (I got no reply on the mailing list yet). Do you have an idea on how to circumvent this problem? Thanks, Volker Original Message Subject: [gdal-dev] problem with decimal precision (SAGA driver) Date: Mon, 04 Apr 2011 15:11:21 +0200 From: Volker Wichmann volker.wichm...@uibk.ac.at To: gdal-dev gdal-dev@lists.osgeo.org Hi, we encountered a problem with decimal precision when converting a SAGA grid to ESRI ASCII. I expect the problem arising from ASCII to double conversion by atof() and/or from the Geotransform (pixel as point to pixel as area). The SAGA header looks like POSITION_XMIN = 12181.80 POSITION_YMIN = 219184.88 CELLSIZE= 1.00 The final ESRI ASCII header looks like xllcorner12181.2999 yllcorner219184.3805 instead of xllcorner12181.3 yllcorner219184.38 How is this problem handled in other drivers (using strtod(), stringstream, ...)? The relevant lines of code in sagadataset.cpp (http://trac.osgeo.org/gdal/browser/trunk/gdal/frmts/saga/sagadataset.cpp) are: 406dXmin = atof(papszTokens[1]); 408dYmin = atof(papszTokens[1]); 410dCellsize = atof(papszTokens[1]); 601padfGeoTransform[0] = poGRB-m_Xmin - poGRB-m_Cellsize / 2; 602padfGeoTransform[3] = poGRB-m_Ymin + (nRasterYSize - 1) * poGRB-m_Cellsize + poGRB-m_Cellsize / 2; Thanks, Volker ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] OGR and spatialite View
Dear all, I have created a spatialite View and ogrinfo does not see any spatialite View. Is there some error in my data? Is it OGR able to read spatialite View? Thank you, a - Andrea Borruso email: aborr...@tin.it website: http://blog.spaziogis.it my 2.0 life: http://aborruso.spaziogis.it feed: http://feeds2.feedburner.com/Tanto 38° 7' 48 N, 13° 21' 9 E -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/OGR-and-spatialite-View-tp6265313p6265313.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] gdalinfo doesn't show GEOS projection info
Greetings, I'm working with hdf5 file with the following attributes: (obtained with hdfview) http://osgeo-org.1803224.n2.nabble.com/file/n6265339/hdf5view.bmp However, when I gdalinfo the file, I get the following information: Driver: HDF5Image/HDF5 Dataset Files: none associated Size is 1701, 651 Coordinate System is: 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]] Corner Coordinates: Upper Left (0.0,0.0) Lower Left (0.0, 651.0) Upper Right ( 1701.0,0.0) Lower Right ( 1701.0, 651.0) Center ( 850.5, 325.5) Band 1 Block=1701x1 Type=Int16, ColorInterp=Undefined Metadata: DSSF:CLASS=Data DSSF:PRODUCT=DSSF DSSF:PRODUCT_ID=111 DSSF:N_COLS=1701 DSSF:N_LINES=651 DSSF:NB_BYTES=2 DSSF:SCALING_FACTOR=10 DSSF:OFFSET=0 DSSF:MISSING_VALUE=-1 DSSF:UNITS=W/m**2 DSSF:CAL_SLOPE=1 DSSF:CAL_OFFSET=0 So, basically I can't see in the gdalinfo the following information: +) Proyection used +) Origin +) Pixel size In fact, when I do gdal-translate the file created is not georeferenced rightly. In my opinion, the problem is that the hdf5 attributes are imcomplete or not rightly defined, Please let me know your opinion Many thanks in advance and best regards, Rafa -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/gdalinfo-doesn-t-show-GEOS-projection-info-tp6265339p6265339.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] ArcSDE: connection times too long
Hi listers. I'm seing a very long delay while connecting to ArcSDE. Even if I just do ogrinfo on a single layer I still have to wait a few minutes before I get anything back. Any parameter I can use? Thanks, Duarte ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdalinfo doesn't show GEOS projection info
On 11-04-12 10:24 AM, kingkastle wrote: Greetings, I'm working with hdf5 file with the following attributes: (obtained with hdfview) http://osgeo-org.1803224.n2.nabble.com/file/n6265339/hdf5view.bmp However, when I gdalinfo the file, I get the following information: Driver: HDF5Image/HDF5 Dataset Files: none associated Size is 1701, 651 Coordinate System is: 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]] Corner Coordinates: Upper Left (0.0,0.0) Lower Left (0.0, 651.0) Upper Right ( 1701.0,0.0) Lower Right ( 1701.0, 651.0) Center ( 850.5, 325.5) ... So, basically I can't see in the gdalinfo the following information: +) Proyection used +) Origin +) Pixel size In fact, when I do gdal-translate the file created is not georeferenced rightly. In my opinion, the problem is that the hdf5 attributes are imcomplete or not rightly defined, Please let me know your opinion Many thanks in advance and best regards, Rafa, One challenge with HDF5 (and HDF4) products is that coordinate system and other georeferencing metadata may be included in a wide variety of forms. This aspect is not well standardized - or at least the standards that exist are often not followed. So, in this case, GDAL is not able to deduce the coordinate system or geotransform. It seems like there *might* be enough metadata available to construct coordinate system information for this dataset but it would likely require a fair amount of fooling around to implement and verify. If the data is public you might want to file a GDAL ticket with a pointer to the dataset and the metadata report along with a request to support this georeferencing format. But I must confess I am unlikely to work on it unless I have client interest. 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] gdalinfo doesn't show GEOS projection info
Hi Rafa According to my research on this matter, these HDF5 files (from LANDSAF, I presume) are not georeferenced in a way that GDAL can recognize. There is in fact some information regarding the coordinate system in the HDF5 file, but it is stored on the metadata of the root of the HDF5 file, which is something that GDAL can't read (at least my 1.7.3 version can't). The solution I have found for this is to use some other program (in my case, the pytables python module) to extract this information. After having this info it is still necessary to add some GCPs to the files, in order to georeference them (still with the GEOS projection) in a way that is understandable by GDAL. In order to obtain the coordinates of the GCPs, I am using some reference formulas from the LANDSAF PUMs, which will convert from pixel coordinate to latlon and then proj4's cs2cs utility to convert them to the GEOS projection. Finally I use the gdal_translate utility to add the GCPs to the file. In the end, a gdalwarp can be used to reproject the file from GEOS projection to another projection. This is basically what I am doing in the script that I sent you (off-list). If someone has another technique for georeferencing LANDSAF HDF5 files I'd also be very interesetd in it ;) Best regards On Tue, Apr 12, 2011 at 3:24 PM, kingkastle kingkastle4...@gmail.com wrote: Greetings, I'm working with hdf5 file with the following attributes: (obtained with hdfview) http://osgeo-org.1803224.n2.nabble.com/file/n6265339/hdf5view.bmp However, when I gdalinfo the file, I get the following information: Driver: HDF5Image/HDF5 Dataset Files: none associated Size is 1701, 651 Coordinate System is: 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]] Corner Coordinates: Upper Left ( 0.0, 0.0) Lower Left ( 0.0, 651.0) Upper Right ( 1701.0, 0.0) Lower Right ( 1701.0, 651.0) Center ( 850.5, 325.5) Band 1 Block=1701x1 Type=Int16, ColorInterp=Undefined Metadata: DSSF:CLASS=Data DSSF:PRODUCT=DSSF DSSF:PRODUCT_ID=111 DSSF:N_COLS=1701 DSSF:N_LINES=651 DSSF:NB_BYTES=2 DSSF:SCALING_FACTOR=10 DSSF:OFFSET=0 DSSF:MISSING_VALUE=-1 DSSF:UNITS=W/m**2 DSSF:CAL_SLOPE=1 DSSF:CAL_OFFSET=0 So, basically I can't see in the gdalinfo the following information: +) Proyection used +) Origin +) Pixel size In fact, when I do gdal-translate the file created is not georeferenced rightly. In my opinion, the problem is that the hdf5 attributes are imcomplete or not rightly defined, Please let me know your opinion Many thanks in advance and best regards, Rafa -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/gdalinfo-doesn-t-show-GEOS-projection-info-tp6265339p6265339.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 -- ___ ___ __ Ricardo Garcia Silva ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ArcSDE: connection times too long
On 11-04-12 10:33 AM, Duarte Carreira wrote: Hi listers. I’m seing a very long delay while connecting to ArcSDE. Even if I just do ogrinfo on a single layer I still have to wait a few minutes before I get anything back. Any parameter I can use? Duarte, The SDE driver docs at http://www.gdal.org/ogr/drv_sde.html says: If the layer parameter is specified then the SDE driver is able to skip reading the summary metadata for each layer; skipping this step can be a significant time savings. So try listing the layer of interest in the connection string. SDE:server,instance,database,username,password,layer 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] OGR and spatialite View
Andrea, Try to explicitly ask for the view as a layer with ogrinfo. You can also try to set the SQLITE_LIST_ALL_TABLES environment variable to TRUE. On Tue, Apr 12, 2011 at 7:46 PM, iomeneandrei aborr...@tin.it wrote: Dear all, I have created a spatialite View and ogrinfo does not see any spatialite View. Is there some error in my data? Is it OGR able to read spatialite View? Thank you, a - Andrea Borruso email: aborr...@tin.it website: http://blog.spaziogis.it my 2.0 life: http://aborruso.spaziogis.it feed: http://feeds2.feedburner.com/Tanto 38° 7' 48 N, 13° 21' 9 E -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/OGR-and-spatialite-View-tp6265313p6265313.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 -- 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
[gdal-dev] ftp user and password with vsizip/vsicurl
Is it possible to use vsizip and vsicurl on a password protected ftp site? Something like this command with user and password passed somehow: ogrinfo -ro -al -so /vsizip/vsicurl/ftp://example.com/foldername/file.zip/example.shp I rather hopefully tried some switches, -user:user -password:password, which did not work. Thanks for the vsi support, it is awesome! For vsizip/gz/tar, I find this wiki page very useful, http://trac.osgeo.org/gdal/wiki/UserDocs/ReadInZip I can find all the gdal drivers that support virtual files by following the directions on that page (driver marked with 'v' when running 'gdalinfo --formats'). I tried a similar approach for ogr (ogrinfo --formats and looked for 'v') without learning much. Is there a way to determine virtual file support in ogr? I found that shp is supported by successfully testing it and recalling an IRC mention. Most of what I find for vsicurl is here, http://trac.osgeo.org/gdal/wiki/Release/1.8.0-News Is there somewhere else that I should look for documentation on vsicurl? I gave a shot at adding information to the vsizip wiki page, can someone review it to make sure that I am not spreading false information and correct or delete it if needed? I added to the vsizip page rather than making a different page since vsicurl is often used with vsizip. Currently, the example commands that I put there give an error claiming that the .shx is corrupt. For instance, ogrinfo -ro -al -so /vsicurl/http://trac.osgeo.org/gdal/browser/trunk/autotest/ogr/data/poly.shp Any help appreciated, Eli ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Connection to SQL Server 2008
Hello List, We have encountered a problem on version 1.7 of QGIS (dev) can support the connection to SQL Server 2008. When it connects to the base layer does not contain any vector object and the attribute table contains the correct columns and many rows, but they all contain ERROR ... Same problem on version 1.8 of GDAL : When it connects to the base layer for export table to shapefile, error is : Unable to open datasource `MSSQL:server=.\SQLSERVER;database=ObservatoireCommerce;tables=dbo.T_ CommuneGeographie;trusted_connection=yes' with the fo llowing drivers. One of you has it managed to run this connection? Thank you! Christophe Baume Code : the sql table(2008) is defined as : CREATE TABLE [dbo].[T_CommuneGeographie]( [COMGEO_Id] [uniqueidentifier] ROWGUIDCOL NOT NULL, [COMGEO_Commune_COM_Id] [uniqueidentifier] NOT NULL, [COMGEO_Geographie] [geography] NOT NULL, [COMGEO_DateDebut] [date] NULL, [COMGEO_DateFin] [date] NULL, CONSTRAINT [PK_T_CommuneGeographie] PRIMARY KEY CLUSTERED ( [COMGEO_Id] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF , ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] the lines entered into the console: ogr2ogr -overwrite -f ESRI Shapefile c:/test/test.shp MSSQL:server=.\SQLSERVER;database=ObservatoireCommerce;tables=dbo.T_CommuneGeographie;trusted_connection=yes the lines entered into the python console: conn_string = MSSQL:server=.\SQLExpress;database=ObservatoireCommerce;trusted_connection=yes;tables=dbo.T_CommuneGeographie qgis.utils.iface.addVectorLayer(conn_string,'test','ogr') ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
RE: [gdal-dev] ArcSDE: connection times too long
Hi Frank. I do that already: ogrinfo -so -ro SDE:server,5151,,user,pdw user.featureclass Notice that I separate the layer name with a blank space. Using a comma does not work for me (wonder if the docs are right on that??). I still wait quite a bit. This is a mid-sized db, with some 1200 feature classes... Duarte -Mensagem original- De: Frank Warmerdam [mailto:warmer...@pobox.com] Enviada: terça-feira, 12 de Abril de 2011 15:47 Para: gdal-dev@lists.osgeo.org Assunto: Re: [gdal-dev] ArcSDE: connection times too long On 11-04-12 10:33 AM, Duarte Carreira wrote: Hi listers. I'm seing a very long delay while connecting to ArcSDE. Even if I just do ogrinfo on a single layer I still have to wait a few minutes before I get anything back. Any parameter I can use? Duarte, The SDE driver docs at http://www.gdal.org/ogr/drv_sde.html says: If the layer parameter is specified then the SDE driver is able to skip reading the summary metadata for each layer; skipping this step can be a significant time savings. So try listing the layer of interest in the connection string. SDE:server,instance,database,username,password,layer 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] ArcSDE: connection times too long
On 11-04-12 12:12 PM, Duarte Carreira wrote: Hi Frank. I do that already: ogrinfo -so -ro SDE:server,5151,,user,pdw user.featureclass Notice that I separate the layer name with a blank space. Using a comma does not work for me (wonder if the docs are right on that??). I still wait quite a bit. This is a mid-sized db, with some 1200 feature classes... Duarte, In your case you are passing user.featureclass as the layer name to ogrinfo telling it that you only want to report on that layer. But to avoid opening all layers, you should also include it in the connection string. eg. ogrinfo -so -ro SDE:server,5151,,user,pdw,user.featureclass user.featureclass 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] ArcSDE: connection times too long
That never occurred to me! Ok, so I measured 48secs sharp to get ogrinfo results, by including the featureclass name in the connection and after that too (like you pointed out). Then got 45secs with just the name in the connection, and got all layers listed. Don't know what to make of this... Duarte -Mensagem original- De: Frank Warmerdam [mailto:warmer...@pobox.com] Enviada: terça-feira, 12 de Abril de 2011 17:32 Para: Duarte Carreira Cc: gdal-dev@lists.osgeo.org Assunto: Re: [gdal-dev] ArcSDE: connection times too long On 11-04-12 12:12 PM, Duarte Carreira wrote: Hi Frank. I do that already: ogrinfo -so -ro SDE:server,5151,,user,pdw user.featureclass Notice that I separate the layer name with a blank space. Using a comma does not work for me (wonder if the docs are right on that??). I still wait quite a bit. This is a mid-sized db, with some 1200 feature classes... Duarte, In your case you are passing user.featureclass as the layer name to ogrinfo telling it that you only want to report on that layer. But to avoid opening all layers, you should also include it in the connection string. eg. ogrinfo -so -ro SDE:server,5151,,user,pdw,user.featureclass user.featureclass 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
[gdal-dev] Re: FileGDB OGR driver test
On 04/04/2011 05:05, Ragi Burhum wrote: Hello list, I am trying to test a new version of the FileGDB driver for OGR, but I lack enough FileGDBs to test :) Is the lack of FileGDBs still an issue? At work, we have several hundreds of them and I could check if I can make some available. If you have an *ArcGIS 10* FileGDB and would like to test the FileGDB driver (and report back), feel free to grab a gdal-trunk binary I made for Windows. A related question: will there ever be a FileGDB driver for a non-Windows OS? Is this feasible at all? Hermann ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: FileGDB OGR driver test
Hermann, You can use the FileGDB driver with Linux. The FileGDB api has been available on Linux since Beta 2. I plan to do some testing in the next couple of days. Mike -- Michael Smith Remote Sensing/GIS Center US Army Corps of Engineers On 4/12/11 1:08 PM, Hermann Peifer pei...@gmx.eu wrote: On 04/04/2011 05:05, Ragi Burhum wrote: Hello list, I am trying to test a new version of the FileGDB driver for OGR, but I lack enough FileGDBs to test :) Is the lack of FileGDBs still an issue? At work, we have several hundreds of them and I could check if I can make some available. If you have an *ArcGIS 10* FileGDB and would like to test the FileGDB driver (and report back), feel free to grab a gdal-trunk binary I made for Windows. A related question: will there ever be a FileGDB driver for a non-Windows OS? Is this feasible at all? Hermann ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Re: OGR and spatialite View
Chaitanya, Chaitanya kumar CH wrote: Try to explicitly ask for the view as a layer with ogrinfo. You can also try to set the SQLITE_LIST_ALL_TABLES environment variable to TRUE. I have set the SQLITE_LIST_ALL_TABLES environment variable to TRUE, and now it works. Thank you very much, Andrea - Andrea Borruso email: aborr...@tin.it website: http://blog.spaziogis.it my 2.0 life: http://aborruso.spaziogis.it feed: http://feeds2.feedburner.com/Tanto 38° 7' 48 N, 13° 21' 9 E -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/OGR-and-spatialite-View-tp6265313p6266042.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] Re: OGR/Spatialite patches
Hi there. Since Berkeley DB is SQLite API compatible, does anybody has experience with using Berkeley DB + Spatialite ? Would that be possible to work? Thanks, Ivan ---Original Message--- From: Even Rouault even.roua...@mines-paris.org To: Alessandro Furieri a.furi...@lqt.it, Frank Warmerdam warmer...@pobox.com Cc: Andrea Peri andrea.p...@regione.toscana.it, gdal-dev@lists.osgeo.org, Paolo Cavallini cavall...@faunalia.it, Sandro Santilli s...@keybit.net, Maurizio Napolitano n...@fbk.eu, Alex Mandel tech_...@wildintellect.com Subject: [gdal-dev] Re: OGR/Spatialite patches Sent: Mar 30 '11 15:07 Hi Alessandro, (CC'ing gdal-dev) Impressive work ! My remarks and questions: 1) Could you confirm that all this work might be included under the usual GDAL X/MIT licence ? Due to the significant code addition for the 3D geometry support, you might want to add your copyright in the header of ogrsqlitelayer.cpp. 2) It would be really convenient to have different patches for the different issues that could be applied sequentially. Applying all this stuff in a single gulp will make bisection and analysis of the changes quite painfull. I've skimmed quickly through the whole diff and your README and I can see several patches, preferably in the following order (if possible) : 1) 3D geometry support 2) use the spatialite SQL functions and drop the manual workarounds to avoid using spatialite functions 3) general cleanup to remove the use of ancient sqlite API (that seem not to be directly related to spatialite support) I'd be in favor of dropping the stuff related to #ifdef SPATIALITE_AMALGAMATION for now. Or it might be traced under a different ticket 3) From your patch I can see that my efforts to produce a spatialite database without linking to spatialite were vain. I'm not that surprised however So the question is : is there really an interest in allowing the user to create a spatialite database without linking to spatialite if that database cannot be directly used by other spatialite-enabled software ant that the user must repair it afterwards with the procedure at the end of your README.txt. This really sounds to be compatible with only super power users... We might also want to be sure that no write/update/delete operations can happen to a spatialite database if it is opened with a driver not linked against libspatialite to avoid corrupting it. However I think it is still desirable to be able to read a spatialite database without requiring linking to spatialite. 4) We must be aware that using the ALTER TABLE ... ADD COLUMN ... stuff will produce databases (even regular SQLite ones) that will not be compatible with the latest FWTools for Windows that uses an ancient sqlite versions. Might not be a big deal however because I somehow remember that dropping a new version of sqlite3.dll in the bin directory make it work again. 5) Would you be willing to update/extend the autotest/ogr/ogr_sqlite.py test to ensure that it still passes and add some tests for all the new stuff, particularly the 3D geometry support. 6) From your README.TXT, can I assume that your changes have been tested against regular libsqlite3 (without linking to spatialite) with a spatialite database (and also a regular sqlite database not using spatialite geometries), and against libspatialite 2.3.1 and libspatialite 2.4.0 for spatialite databases ? 7) A minor code note : it could be interesting to replace the magic values for the geometry types by appropriate #define with symbolic names. 8) I've seen you have removed the tests to detect int overflows, for example if( nPointCount 0 || nPointCount INT_MAX / (2 * 8)) has become if( nPointCount 0). Could you justify it ? I still think that they are necessary to avoid issues in lines below if the nPointCount value is huge enough. 9) About your [3c] patch. Yes indeed this is a painfull issue with shapefiles (the format I mean, not the driver) where we cannot know in advance if it only contains LINESTRING or MULTILINESTRING. Currently the shapefile driver chooses to report the layer as having LINESTRING geometry type. Maybe Frank can comment about this. I imagine this was decided because some application software wouldn't know to deal with multi-geometry. But I can confirm that inserting such shapefiles with mixed linestring/multilinestring geometries into Postgis requires a -nlt flag to the ogr2ogr command line. To get back to your patch, I'm wondering what will happen if we try to insert a feature with a LINESTRING geometry into a layer created with the LINESTRING geometry type, that has been promoted to MULTILINESTRING by the driver ? Best regards, Even Le mercredi 30 mars 2011 12:37:05, Alessandro Furieri a écrit : Hi All, I know for sure that all you are
[gdal-dev] Reading of MSG Native Data
Hi, I've been testing GDAL with Native (.nat) format data from the MSG satellite, and have a slight problem. gdal_translate fails to process the high resolution channel (Band 12, image size is variable but for my data 5568x4176). The .nat files I'm working with only contain the HRV data, not the low res channels - but when I run gdalinfo the data I see listed looks like it is for the low res channels (image size of 3712x3712 and pixel size of 3km). It may also be reading the wrong satellite position (0 degrees instead of 9.5E) although this may be a problem with the actual .nat file. gdalinfo also displays an error (ERROR 1: tolerance condition error) for the corner coordinates of the image.. Is this a known issue? It would be great if there is a work-around for it. All the best, Simon. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ftp user and password with vsizip/vsicurl
Le mardi 12 avril 2011 17:26:02, Eli Adam a écrit : Is it possible to use vsizip and vsicurl on a password protected ftp site? Something like this command with user and password passed somehow: ogrinfo -ro -al -so /vsizip/vsicurl/ftp://example.com/foldername/file.zip/example.shp I rather hopefully tried some switches, -user:user -password:password, which did not work. I've just tried with an FTP site and ogrinfo -ro -al -so /vsizip/vsicurl/ftp://user:passw...@example.com/foldername/file.zip/example.shp works Thanks for the vsi support, it is awesome! For vsizip/gz/tar, I find this wiki page very useful, http://trac.osgeo.org/gdal/wiki/UserDocs/ReadInZip I can find all the gdal drivers that support virtual files by following the directions on that page (driver marked with 'v' when running 'gdalinfo --formats'). I tried a similar approach for ogr (ogrinfo --formats and looked for 'v') without learning much. Is there a way to determine virtual file support in ogr? I found that shp is supported by successfully testing it and recalling an IRC mention. No, there's no easy way of knowing if an OGR driver supports VSI virtual file handlers such as vsizip, vsicurl etc... From a quick grep -r VSILFILE ogr/ogrsf_frmts/, I can see in current trunk (might not be the case for all drivers in GDAL 1.8.0 as a few have been converted since the release), that CSV, PGDUMP (well, this is just write- only), SVG, KML, HTF, DXF, PDS, VRT, GPX, AERONAVFAA, GTM, EDIGEO, SHAPE, OPENAIR, LIBKML, GEORSS, GPSBABEL, BNA, GEOJSON, XPLANE, GMT, GML, SUA and S57 use the VSI virtual file API at least partially. Caution : It doesn't mean that they are all fully vetted to be compatible with it. Most of what I find for vsicurl is here, http://trac.osgeo.org/gdal/wiki/Release/1.8.0-News Is there somewhere else that I should look for documentation on vsicurl? I gave a shot at adding information to the vsizip wiki page, can someone review it to make sure that I am not spreading false information and correct or delete it if needed? I added to the vsizip page rather than making a different page since vsicurl is often used with vsizip. There's some info in the doc of VSIInstallCurlFileHandler() here http://gdal.org/cpl__vsi_8h.html#4f791960f2d86713d16e99e9c0c36258 You might want to add the link to it, like it is done for the other special file handlers in the page. Currently, the example commands that I put there give an error claiming that the .shx is corrupt. For instance, ogrinfo -ro -al -so /vsicurl/http://trac.osgeo.org/gdal/browser/trunk/autotest/ogr/data/poly.s hp This was just a bad URL. ogrinfo -ro -al -so /vsicurl/http://svn.osgeo.org/gdal/trunk/autotest/ogr/data/poly.shp works Any help appreciated, Eli ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: FileGDB OGR driver test
Le mardi 12 avril 2011 19:08:24, Hermann Peifer a écrit : On 04/04/2011 05:05, Ragi Burhum wrote: Hello list, I am trying to test a new version of the FileGDB driver for OGR, but I lack enough FileGDBs to test :) Is the lack of FileGDBs still an issue? At work, we have several hundreds of them and I could check if I can make some available. ArcGIS 10 FileGDB's right ? Yes real data would be usefull. But it would also be usefull if you (or anyone else) could provide small and freely redistribuable samples (potentially fake data) with different types of geometries (1 feature for each geometry type is enough in theory), column types (integer, single, double, string, date), etc.. so that it can be included in the GDAL/OGR autotest suite. If you have an *ArcGIS 10* FileGDB and would like to test the FileGDB driver (and report back), feel free to grab a gdal-trunk binary I made for Windows. A related question: will there ever be a FileGDB driver for a non-Windows OS? Is this feasible at all? Current GDAL trunk builds against FileGDB API beta3 under Linux 32bit. Too bad ESRI doesn't provide any 64bit build of the FileGDB API (yet... ?) Hermann ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: FileGDB OGR driver test
Even, How do you configure gdal/ogr to build with the linux api? I'm working on getting some example datasets together. Mike -- Michael Smith Remote Sensing/GIS Center US Army Corps of Engineers On 4/12/11 2:28 PM, Even Rouault even.roua...@mines-paris.org wrote: Le mardi 12 avril 2011 19:08:24, Hermann Peifer a écrit : On 04/04/2011 05:05, Ragi Burhum wrote: Hello list, I am trying to test a new version of the FileGDB driver for OGR, but I lack enough FileGDBs to test :) Is the lack of FileGDBs still an issue? At work, we have several hundreds of them and I could check if I can make some available. ArcGIS 10 FileGDB's right ? Yes real data would be usefull. But it would also be usefull if you (or anyone else) could provide small and freely redistribuable samples (potentially fake data) with different types of geometries (1 feature for each geometry type is enough in theory), column types (integer, single, double, string, date), etc.. so that it can be included in the GDAL/OGR autotest suite. If you have an *ArcGIS 10* FileGDB and would like to test the FileGDB driver (and report back), feel free to grab a gdal-trunk binary I made for Windows. A related question: will there ever be a FileGDB driver for a non-Windows OS? Is this feasible at all? Current GDAL trunk builds against FileGDB API beta3 under Linux 32bit. Too bad ESRI doesn't provide any 64bit build of the FileGDB API (yet... ?) Hermann ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: FileGDB OGR driver test
ArcGIS 10 FileGDB's right ? If the api allows for using gdb's from different versions then the test suite should have different versions too. In any case I can make v10 gdb's. Current GDAL trunk builds against FileGDB API beta3 under Linux 32bit. Too bad ESRI doesn't provide any 64bit build of the FileGDB API (yet... ?) We are working on a Linux 64-bit release of the File Geodatabase API. It will not release with the 1.0 release of the API, but as a part of a follow on release later this year. Lance Shipman Geodatabase Product Engineer, File Geodatabase esri -- http://forums.arcgis.com/threads/3-Cross-plattform-API?p=89593viewfull=1#post89593 -matt ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: FileGDB OGR driver test
Le mardi 12 avril 2011 20:37:06, Smith, Michael ERDC-CRREL-NH a écrit : Even, How do you configure gdal/ogr to build with the linux api? This is a bit involved since there's no ./configure support yet, so I compile it at hand as a plugin Here's the line I use from GDAL root source directory : g++ -Wall -g ogr/ogrsf_frmts/filegdb/*.c* -shared -o ogr_filegdb.so -Iport - Igcore -Iogr -Iogr/ogrsf_frmts -Iogr/ogrsf_frmts/filegdb -L. -lgdal - I/home/even/filegdb/dist/include -L/home/even/filegdb/dist/lib - I/home/even/filegdb/dist/src/FileGDBEngine/include/FileGDBLinux -lFileGDBAPI You must change the /home/even/filegdb/ paths to where you uncompress the filegdb API And you must define the GDAL_DRIVER_PATH environmenet variable to point to the path where ogr_filegdb.so is I'm working on getting some example datasets together. Mike Le mardi 12 avril 2011 19:08:24, Hermann Peifer a écrit : On 04/04/2011 05:05, Ragi Burhum wrote: Hello list, I am trying to test a new version of the FileGDB driver for OGR, but I lack enough FileGDBs to test :) Is the lack of FileGDBs still an issue? At work, we have several hundreds of them and I could check if I can make some available. ArcGIS 10 FileGDB's right ? Yes real data would be usefull. But it would also be usefull if you (or anyone else) could provide small and freely redistribuable samples (potentially fake data) with different types of geometries (1 feature for each geometry type is enough in theory), column types (integer, single, double, string, date), etc.. so that it can be included in the GDAL/OGR autotest suite. If you have an *ArcGIS 10* FileGDB and would like to test the FileGDB driver (and report back), feel free to grab a gdal-trunk binary I made for Windows. A related question: will there ever be a FileGDB driver for a non-Windows OS? Is this feasible at all? Current GDAL trunk builds against FileGDB API beta3 under Linux 32bit. Too bad ESRI doesn't provide any 64bit build of the FileGDB API (yet... ?) Hermann ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: FileGDB OGR driver test
Le mardi 12 avril 2011 20:40:58, Matt Wilkie a écrit : ArcGIS 10 FileGDB's right ? If the api allows for using gdb's from different versions then the test suite should have different versions too. In any case I can make v10 gdb's. No, the FileGDB API only reads v10 gdb's. Current GDAL trunk builds against FileGDB API beta3 under Linux 32bit. Too bad ESRI doesn't provide any 64bit build of the FileGDB API (yet... ?) We are working on a Linux 64-bit release of the File Geodatabase API. It will not release with the 1.0 release of the API, but as a part of a follow on release later this year. Lance Shipman Geodatabase Product Engineer, File Geodatabase esri ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ftp user and password with vsizip/vsicurl
Even, I've added most of this to the wiki. I've also corrected the urls that were incorrect. http://trac.osgeo.org/gdal/wiki/UserDocs/ReadInZip#vsicurl-toreadfromHTTPorFTPfilespartialdownloading Thanks, Eli On 4/12/2011 at 11:11 AM, in message 201104122011.20768.even.roua...@mines-paris.org, Even Rouault even.roua...@mines-paris.org wrote: Le mardi 12 avril 2011 17:26:02, Eli Adam a écrit : Is it possible to use vsizip and vsicurl on a password protected ftp site? Something like this command with user and password passed somehow: ogrinfo -ro -al -so /vsizip/vsicurl/ftp://example.com/foldername/file.zip/example.shp I rather hopefully tried some switches, -user:user -password:password, which did not work. I've just tried with an FTP site and ogrinfo -ro -al -so /vsizip/vsicurl/ftp://user:passw...@example.com/foldername/file.zip/example. shp works Thanks for the vsi support, it is awesome! For vsizip/gz/tar, I find this wiki page very useful, http://trac.osgeo.org/gdal/wiki/UserDocs/ReadInZip I can find all the gdal drivers that support virtual files by following the directions on that page (driver marked with 'v' when running 'gdalinfo --formats'). I tried a similar approach for ogr (ogrinfo --formats and looked for 'v') without learning much. Is there a way to determine virtual file support in ogr? I found that shp is supported by successfully testing it and recalling an IRC mention. No, there's no easy way of knowing if an OGR driver supports VSI virtual file handlers such as vsizip, vsicurl etc... From a quick grep -r VSILFILE ogr/ogrsf_frmts/, I can see in current trunk (might not be the case for all drivers in GDAL 1.8.0 as a few have been converted since the release), that CSV, PGDUMP (well, this is just write- only), SVG, KML, HTF, DXF, PDS, VRT, GPX, AERONAVFAA, GTM, EDIGEO, SHAPE, OPENAIR, LIBKML, GEORSS, GPSBABEL, BNA, GEOJSON, XPLANE, GMT, GML, SUA and S57 use the VSI virtual file API at least partially. Caution : It doesn't mean that they are all fully vetted to be compatible with it. Most of what I find for vsicurl is here, http://trac.osgeo.org/gdal/wiki/Release/1.8.0-News Is there somewhere else that I should look for documentation on vsicurl? I gave a shot at adding information to the vsizip wiki page, can someone review it to make sure that I am not spreading false information and correct or delete it if needed? I added to the vsizip page rather than making a different page since vsicurl is often used with vsizip. There's some info in the doc of VSIInstallCurlFileHandler() here http://gdal.org/cpl__vsi_8h.html#4f791960f2d86713d16e99e9c0c36258 You might want to add the link to it, like it is done for the other special file handlers in the page. Currently, the example commands that I put there give an error claiming that the .shx is corrupt. For instance, ogrinfo -ro -al -so /vsicurl/http://trac.osgeo.org/gdal/browser/trunk/autotest/ogr/data/poly.s hp This was just a bad URL. ogrinfo -ro -al -so /vsicurl/http://svn.osgeo.org/gdal/trunk/autotest/ogr/data/poly.shp works Any help appreciated, Eli ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: FileGDB OGR driver test
I have a test v10 filegdb with points, lines, polygons (all with Z and M but I think the measures aren't populated). There are also some non geometry tables and some relationship classes. Its available at http://12.189.158.78:8081/downloads/test_fgdb.gdb.zip Mike -- Michael Smith Remote Sensing/GIS Center US Army Corps of Engineers On 4/12/11 2:48 PM, Even Rouault even.roua...@mines-paris.org wrote: Le mardi 12 avril 2011 20:40:58, Matt Wilkie a écrit : ArcGIS 10 FileGDB's right ? If the api allows for using gdb's from different versions then the test suite should have different versions too. In any case I can make v10 gdb's. No, the FileGDB API only reads v10 gdb's. Current GDAL trunk builds against FileGDB API beta3 under Linux 32bit. Too bad ESRI doesn't provide any 64bit build of the FileGDB API (yet... ?) We are working on a Linux 64-bit release of the File Geodatabase API. It will not release with the 1.0 release of the API, but as a part of a follow on release later this year. Lance Shipman Geodatabase Product Engineer, File Geodatabase esri ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Dateline gap
Hello: I stopped by the #gdal channel on IRC to ask this question. Thank you for the help provided there. I thought it might be better if I asked a question here so I can better explain what's going on in one spot and not flood the channel. I understand this is a pixel center vs pixel edge issue. My ultimate goal is to get from a netCDF file to a google map overlay contour. The general steps I've taken, which work all the way up to about 178.29 then it just cuts off. netCDF - color-relief PNG using gdaldem color-relief ... PNG - Geocoded PNG using gdal_translate -a_srs EPSG:4326 -outsize 4096 4096 -a_ullr -180.25 90.25 180.25 -90.25 on the PNG (Have also tried this with just -180 90 180 -90 PNG - tiles using gdal2tiles.py -s EPSG:4326 -z 0 -n -w google on the Geocoded PNG I guess first question, is my methodology sound? Maybe there's a better way/tool to approach the problem. Following is the output from gdalinfo, other than that, what information might I be able to provide that could help? Thank you, Jerl gdalinfo for the source netcdf: (My apologies, I'm not certain what is relevant so I'm including most everything.) Driver: netCDF/Network Common Data Format Files: test.nc Size is 721, 361 Coordinate System is `' Origin = (-180.250,90.250) Pixel Size = (0.500,-0.500) Metadata: NC_GLOBAL#Conventions=CF-1.0 NC_GLOBAL#cdm_data_type=GRID NC_GLOBAL#file_format=GEMPAK NC_GLOBAL#location=test.grd NC_GLOBAL#history=Direct read of GEMPAK into NetCDF-Java 4.0 API NC_GLOBAL#_CoordinateModelRunDate=2011-04-12T00:00:00Z UVIN_NONE#long_name=testdata UVIN_NONE#units= UVIN_NONE#missing_value=-9.999000e+03 UVIN_NONE#VectorComponentFlag=gridRelative time#long_name=forecast time time#units=minute since 2011-04-12T00:00:00Z time#_CoordinateAxisType=Time lat#units=degrees_north lat#long_name=latitude coordinate lat#standard_name=latitude lat#grid_spacing=0.5 degrees_north lat#_CoordinateAxisType=Lat lon#units=degrees_east lon#long_name=longitude coordinate lon#standard_name=longitude lon#grid_spacing=0.5 degrees_east lon#_CoordinateAxisType=Lon Corner Coordinates: Upper Left (-180.250, 90.250) Lower Left (-180.250, -90.250) Upper Right ( 180.250, 90.250) Lower Right ( 180.250, -90.250) Center ( 0.000, 0.000) gdalinfo of geocoded PNG: Driver: PNG/Portable Network Graphics Files: testWorld.png testWorld.png.aux.xml Size is 4096, 4096 Coordinate System is: GEOGCS[WGS 84, DATUM[WGS_1984, SPHEROID[WGS 84,6378137,298.257223563, AUTHORITY[EPSG,7030]], AUTHORITY[EPSG,6326]], PRIMEM[Greenwich,0, AUTHORITY[EPSG,8901]], UNIT[degree,0.01745329251994328, AUTHORITY[EPSG,9122]], AUTHORITY[EPSG,4326]] Origin = (-180.000,90.000) Pixel Size = (0.08789062500,-0.04394531250) Image Structure Metadata: INTERLEAVE=PIXEL Corner Coordinates: Upper Left (-180.000, 90.000) (180d 0'0.00W, 90d 0'0.00N) Lower Left (-180.000, -90.000) (180d 0'0.00W, 90d 0'0.00S) Upper Right ( 180.000, 90.000) (180d 0'0.00E, 90d 0'0.00N) Lower Right ( 180.000, -90.000) (180d 0'0.00E, 90d 0'0.00S) Center ( 0.000, 0.000) ( 0d 0'0.01E, 0d 0'0.01N) Band 1 Block=4096x1 Type=Byte, ColorInterp=Red Mask Flags: PER_DATASET ALPHA Band 2 Block=4096x1 Type=Byte, ColorInterp=Green Mask Flags: PER_DATASET ALPHA Band 3 Block=4096x1 Type=Byte, ColorInterp=Blue Mask Flags: PER_DATASET ALPHA Band 4 Block=4096x1 Type=Byte, ColorInterp=Alpha -- This communication is privileged and may contain confidential information. It's intended only for the use of the person or entity named above. If you are not the intended recipient, do not distribute or copy this communication. If you have received this communication in error, please notify the sender immediately and return the original to the email address above. © Copyright 2011 Weather Trends International, Inc. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] gdal datum shift
Trying to get a raster to go from NAD83 to NAD27 with gdalwarp. Can't see any way to tell how it is choosing to do it. Is this documented anywhere? Is there any way to make it verbose so I can tell if it's trying? I ran it through strace and watched it open a file called gdal_datum.csv but of course can't tell what it's trying to do. I found this post from Frank which implies it tries to be smart and figure out the transforms without my help: http://fwarmerdam.blogspot.com/2010/03/in-last-few-weeks-i-believe-i-have-made.html But it's not working and since I don't know how to tell what it's doing I can't intelligently ask for help. :-) Thanks for your patience with a n00by Brian Command I am using: gdalwarp -of HFA -co COMPRESSED=YES -t_srs ESRI::NAD_1927_StatePlane_Oregon_North_FIPS_3601.prj 11s5w34f_color_ne.sid 11s5w34f_color_ne_nad27.img Output is in the right coordinate space (it's moved from meters to feet) but has that familiar 10 or so meter shift we get around like the NAD83-NAD27 transform failed. The input file SRS looks like this Coordinate System is: PROJCS[NAD_1983_HARN_StatePlane_Oregon_North_FIPS_3601, GEOGCS[GCS_North_American_1983_HARN, DATUM[NAD83_High_Accuracy_Regional_Network, SPHEROID[GRS_1980,6378137,298.257222101]], PRIMEM[Greenwich,0], UNIT[Degree,0.017453292519943295]], PROJECTION[Lambert_Conformal_Conic_2SP], PARAMETER[False_Easting,250], PARAMETER[False_Northing,0], PARAMETER[Central_Meridian,-120.5], PARAMETER[Standard_Parallel_1,44.34], PARAMETER[Standard_Parallel_2,46], PARAMETER[Latitude_Of_Origin,43.66], UNIT[Meter,1], AUTHORITY[EPSG,102326]] ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: FileGDB OGR driver test
Hi Hermann, it's so good to hear there is active work on this! I am trying to test a new version of the FileGDB driver for OGR, but I lack enough FileGDBs to test :) Ho many do you need, what kind of contents should they have, and how big? e.g. feature classes, feature datasets, topologies, attribute domains, sub-types, relationship classes, feature representations, etc. For gdb's to test volume, ftp://ftp2.cits.nrcan.gc.ca/pub/canvec/canada_fgdb/ has up to 10gb in size. I have a gdb using a relationship class which can be made available with a bit of work. And another with feature representations due in a couple of months, but I can make private subset release early if it's helpful. I'm willing to create and share other kinds for testing, just let me know what you're looking for. cheers, -- matt wilkie Geomatics Analyst Information Management and Technology Yukon Department of Environment 10 Burns Road * Whitehorse, Yukon * Y1A 4Y9 867-667-8133 Tel * 867-393-7003 Fax http://environmentyukon.gov.yk.ca/geomatics/ ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Dateline gap
Jerl, I would do that with GMT. By using ps2raster you can convert any GMT figure (in geogs of course) into KML, and GMT has excellent care of date line transition issues. Joaquim Hello: I stopped by the #gdal channel on IRC to ask this question. Thank you for the help provided there. I thought it might be better if I asked a question here so I can better explain what's going on in one spot and not flood the channel. I understand this is a pixel center vs pixel edge issue. My ultimate goal is to get from a netCDF file to a google map overlay contour. The general steps I've taken, which work all the way up to about 178.29 then it just cuts off. netCDF - color-relief PNG using gdaldem color-relief ... PNG - Geocoded PNG using gdal_translate -a_srs EPSG:4326 -outsize 4096 4096 -a_ullr -180.25 90.25 180.25 -90.25 on the PNG (Have also tried this with just -180 90 180 -90 PNG - tiles using gdal2tiles.py -s EPSG:4326 -z 0 -n -w google on the Geocoded PNG I guess first question, is my methodology sound? Maybe there's a better way/tool to approach the problem. Following is the output from gdalinfo, other than that, what information might I be able to provide that could help? Thank you, Jerl gdalinfo for the source netcdf: (My apologies, I'm not certain what is relevant so I'm including most everything.) Driver: netCDF/Network Common Data Format Files: test.nc Size is 721, 361 Coordinate System is `' Origin = (-180.250,90.250) Pixel Size = (0.500,-0.500) Metadata: NC_GLOBAL#Conventions=CF-1.0 NC_GLOBAL#cdm_data_type=GRID NC_GLOBAL#file_format=GEMPAK NC_GLOBAL#location=test.grd NC_GLOBAL#history=Direct read of GEMPAK into NetCDF-Java 4.0 API NC_GLOBAL#_CoordinateModelRunDate=2011-04-12T00:00:00Z UVIN_NONE#long_name=testdata UVIN_NONE#units= UVIN_NONE#missing_value=-9.999000e+03 UVIN_NONE#VectorComponentFlag=gridRelative time#long_name=forecast time time#units=minute since 2011-04-12T00:00:00Z time#_CoordinateAxisType=Time lat#units=degrees_north lat#long_name=latitude coordinate lat#standard_name=latitude lat#grid_spacing=0.5 degrees_north lat#_CoordinateAxisType=Lat lon#units=degrees_east lon#long_name=longitude coordinate lon#standard_name=longitude lon#grid_spacing=0.5 degrees_east lon#_CoordinateAxisType=Lon Corner Coordinates: Upper Left (-180.250, 90.250) Lower Left (-180.250, -90.250) Upper Right ( 180.250, 90.250) Lower Right ( 180.250, -90.250) Center ( 0.000, 0.000) gdalinfo of geocoded PNG: Driver: PNG/Portable Network Graphics Files: testWorld.png testWorld.png.aux.xml Size is 4096, 4096 Coordinate System is: GEOGCS[WGS 84, DATUM[WGS_1984, SPHEROID[WGS 84,6378137,298.257223563, AUTHORITY[EPSG,7030]], AUTHORITY[EPSG,6326]], PRIMEM[Greenwich,0, AUTHORITY[EPSG,8901]], UNIT[degree,0.01745329251994328, AUTHORITY[EPSG,9122]], AUTHORITY[EPSG,4326]] Origin = (-180.000,90.000) Pixel Size = (0.08789062500,-0.04394531250) Image Structure Metadata: INTERLEAVE=PIXEL Corner Coordinates: Upper Left (-180.000, 90.000) (180d 0'0.00W, 90d 0'0.00N) Lower Left (-180.000, -90.000) (180d 0'0.00W, 90d 0'0.00S) Upper Right ( 180.000, 90.000) (180d 0'0.00E, 90d 0'0.00N) Lower Right ( 180.000, -90.000) (180d 0'0.00E, 90d 0'0.00S) Center ( 0.000, 0.000) ( 0d 0'0.01E, 0d 0'0.01N) Band 1 Block=4096x1 Type=Byte, ColorInterp=Red Mask Flags: PER_DATASET ALPHA Band 2 Block=4096x1 Type=Byte, ColorInterp=Green Mask Flags: PER_DATASET ALPHA Band 3 Block=4096x1 Type=Byte, ColorInterp=Blue Mask Flags: PER_DATASET ALPHA Band 4 Block=4096x1 Type=Byte, ColorInterp=Alpha ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Dateline gap
Thanks for the GMT suggestions. I've never used it, I'll try it out. Thanks!! Typed with thumbs... On Apr 12, 2011 7:24 PM, Joaquim Luis jl...@ualg.pt wrote: Jerl, I would do that with GMT. By using ps2raster you can convert any GMT figure (in geogs of course) into KML, and GMT has excellent care of date line transition issues. Joaquim Hello: I stopped by the #gdal channel on IRC to ask this question. Thank you for the help provided there. I thought it might be better if I asked a question here so I can better explain what's going on in one spot and not flood the channel. I understand this is a pixel center vs pixel edge issue. My ultimate goal is to get from a netCDF file to a google map overlay contour. The general steps I've taken, which work all the way up to about 178.29 then it just cuts off. netCDF - color-relief PNG using gdaldem color-relief ... PNG - Geocoded PNG using gdal_translate -a_srs EPSG:4326 -outsize 4096 4096 -a_ullr -180.25 90.25 180.25 -90.25 on the PNG (Have also tried this with just -180 90 180 -90 PNG - tiles using gdal2tiles.py -s EPSG:4326 -z 0 -n -w google on the Geocoded PNG I guess first question, is my methodology sound? Maybe there's a better way/tool to approach the problem. Following is the output from gdalinfo, other than that, what information might I be able to provide that could help? Thank you, Jerl gdalinfo for the source netcdf: (My apologies, I'm not certain what is relevant so I'm including most everything.) Driver: netCDF/Network Common Data Format Files: test.nc Size is 721, 361 Coordinate System is `' Origin = (-180.250,90.250) Pixel Size = (0.500,-0.500) Metadata: NC_GLOBAL#Conventions=CF-1.0 NC_GLOBAL#cdm_data_type=GRID NC_GLOBAL#file_format=GEMPAK NC_GLOBAL#location=test.grd NC_GLOBAL#history=Direct read of GEMPAK into NetCDF-Java 4.0 API NC_GLOBAL#_CoordinateModelRunDate=2011-04-12T00:00:00Z UVIN_NONE#long_name=testdata UVIN_NONE#units= UVIN_NONE#missing_value=-9.999000e+03 UVIN_NONE#VectorComponentFlag=gridRelative time#long_name=forecast time time#units=minute since 2011-04-12T00:00:00Z time#_CoordinateAxisType=Time lat#units=degrees_north lat#long_name=latitude coordinate lat#standard_name=latitude lat#grid_spacing=0.5 degrees_north lat#_CoordinateAxisType=Lat lon#units=degrees_east lon#long_name=longitude coordinate lon#standard_name=longitude lon#grid_spacing=0.5 degrees_east lon#_CoordinateAxisType=Lon Corner Coordinates: Upper Left (-180.250, 90.250) Lower Left (-180.250, -90.250) Upper Right ( 180.250, 90.250) Lower Right ( 180.250, -90.250) Center ( 0.000, 0.000) gdalinfo of geocoded PNG: Driver: PNG/Portable Network Graphics Files: testWorld.png testWorld.png.aux.xml Size is 4096, 4096 Coordinate System is: GEOGCS[WGS 84, DATUM[WGS_1984, SPHEROID[WGS 84,6378137,298.257223563, AUTHORITY[EPSG,7030]], AUTHORITY[EPSG,6326]], PRIMEM[Greenwich,0, AUTHORITY[EPSG,8901]], UNIT[degree,0.01745329251994328, AUTHORITY[EPSG,9122]], AUTHORITY[EPSG,4326]] Origin = (-180.000,90.000) Pixel Size = (0.08789062500,-0.04394531250) Image Structure Metadata: INTERLEAVE=PIXEL Corner Coordinates: Upper Left (-180.000, 90.000) (180d 0'0.00W, 90d 0'0.00N) Lower Left (-180.000, -90.000) (180d 0'0.00W, 90d 0'0.00S) Upper Right ( 180.000, 90.000) (180d 0'0.00E, 90d 0'0.00N) Lower Right ( 180.000, -90.000) (180d 0'0.00E, 90d 0'0.00S) Center ( 0.000, 0.000) ( 0d 0'0.01E, 0d 0'0.01N) Band 1 Block=4096x1 Type=Byte, ColorInterp=Red Mask Flags: PER_DATASET ALPHA Band 2 Block=4096x1 Type=Byte, ColorInterp=Green Mask Flags: PER_DATASET ALPHA Band 3 Block=4096x1 Type=Byte, ColorInterp=Blue Mask Flags: PER_DATASET ALPHA Band 4 Block=4096x1 Type=Byte, ColorInterp=Alpha ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
