[gdal-dev] GDAL GML driver and .xsd schema mapping
Hi, It is not totally clear for me to what extent GDAL GML driver is utilising the .xsd schema if it is present. I have an example where the schema obviously in not utilised or respected. In the schema the nationalCode element is defined as /element element name=nationalCode type=string annotation documentation-- Definition --#13; Thematic identifier corresponding to the national administrative codes defined in each country.#13; In the GML file the nationalCode attribute has values which are strings but they contain always only numeric characters. The .gfs file created by GDAL is interpreting the attribute data type as Integer. PropertyDefn NamenationalCode/Name ElementPathnationalCode/ElementPath TypeInteger/Type /PropertyDefn Ogr2ogr conversion to other formats gives a correct data type for this attribute if I edit first manually the .gfs file to use String type for nationalCode. I would like to know if this is how it is planned to be and users just need to remember to correct all the strings-with-only-numeric-characters attribute types manually. Perhaps this behaviour has something to do with the data which is using an Inspire schema that cannot be totally converted into ogr model? Comments of ticket 4328 http://trac.osgeo.org/gdal/ticket/4328 especially http://trac.osgeo.org/gdal/changeset/23315 seem to suggest so. If that is a case, could it be possible to make ogr2ogr to print the message /* Too complex schema for us. Aborts parsing */ also on screen as a warning? Otherwise users can believe that the .xsd schema file is used even it is not. I am using the gdal-dev version from this morning (November 14) downloaded from gisinternals. -Jukka Rahkonen-___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] about the license
Hi everyone, I am developing a free software that works with the awesome java bindings of gdal and I have a question about the license and how to use it correctly. This is the first time that I develop a software which is available for download and I want to do this correctly. This is what I have so far. 1.) I have included the gdal.jar, all the required .dll files and the data directory in the program folder. 2.) I put a copy of the license into the program folder. 3.) In the program, you can press a button about go to third-party libraries and read about gdal, the license and links to www.gdal.org Is this enough to meet the requirements of the license? I know this is not really a technical question, but I read a lot of different things about this topic and I am feeling pretty insecure. Greetings Dennis ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] VSIF and Python
Hi, I wanted to try the VSIF* functions that are mentioned in the docs [1]. I am using gdal (and python-gdal) from debian testing, which is version 1.7.?. The VSIF* functions are not found, so I presume they are available with gdal = 1.8 only? I found [2], which is pretty much what I want to do: read geodata with ogr, do some work with it and dump the result, in case of a text file format, to string instead to file. Right now I am doing the same with an extra step (save the result to file and read it again with python). There's no way to inject a file like object (file, stringio) to gdal instead of path names, isn't there? Thanks Frank [1] http://gdal.org/python/ [2] http://osgeo-org.1803224.n2.nabble.com/gdal-dev-NET-and-OGR-writing-to-stream-td6638444.html#a6648549 -- Frank BRONIEWSKI METRICO s.à r.l. géomètres technologies d'information géographique rue des Romains 36 L-5433 NIEDERDONVEN tél.: +352 26 74 94 - 28 fax.: +352 26 74 94 99 http://www.metrico.lu ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] VSIF and Python
Yes, VSI* has been implemented in gdal 1.8.0, you should use the latest stable 1.8.1. You have this in debian experimental, but I don't use debian so can't comment on how experimental the debian gdal 1.8 builds are. You can also build gdal yourself from source. Provided you upgrade to 1.8.1, you should be able to reproduce [2] using the vsimem interface. Etienne On Mon, Nov 14, 2011 at 10:44 AM, Frank Broniewski b...@metrico.lu wrote: Hi, I wanted to try the VSIF* functions that are mentioned in the docs [1]. I am using gdal (and python-gdal) from debian testing, which is version 1.7.?. The VSIF* functions are not found, so I presume they are available with gdal = 1.8 only? I found [2], which is pretty much what I want to do: read geodata with ogr, do some work with it and dump the result, in case of a text file format, to string instead to file. Right now I am doing the same with an extra step (save the result to file and read it again with python). There's no way to inject a file like object (file, stringio) to gdal instead of path names, isn't there? Thanks Frank [1] http://gdal.org/python/ [2] http://osgeo-org.1803224.n2.nabble.com/gdal-dev-NET-and-OGR-writing-to-stream-td6638444.html#a6648549 -- Frank BRONIEWSKI METRICO s.à r.l. géomètres technologies d'information géographique rue des Romains 36 L-5433 NIEDERDONVEN tél.: +352 26 74 94 - 28 fax.: +352 26 74 94 99 http://www.metrico.lu ___ 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] VSIF and Python
On 11/14/2011 02:44 PM, Frank Broniewski wrote:
I want to do: read geodata with ogr, do some work with it and dump the
result, in case of a text file format, to string instead to file.
Right now I am doing the same with an extra step (save the result to
file and read it again with python).
There's no way to inject a file like object (file, stringio) to gdal
instead of path names, isn't there?
This is not an answer and I don't speak for the Python bindings. Instead
I'm looking at this from the
point of view of Perl bindings.
Latest Perl bindings do have the VSIF{Open,Close,Seek,Tell,Write}L API
but they are not documented[1]. Mostly because I haven't used/tried
them. The following is some quick thoughts on how they might be used.
This prints out a shapefile in GML (works now)
use Geo::GDAL;
$datasource = Geo::OGR::Open('/home/ajolma/shapefile.shp');
Geo::OGR::Driver('GML')-Copy($datasource, '/dev/stdout');
The problem with this is I seem to be unable to use any Perl XML/GML
processing tools. It might be useful to do something like this:
use Geo::GDAL;
use XML::Parser;
$datasource = Geo::OGR::Open('/home/ajolma/shapefile.shp');
$handle = Geo::OGR::Driver('GML')-Copy($datasource);
$p = new XML::Parser();
$p-parse($handle);
It seems to me that I'm at least missing a method to get the VSILFILE
name to be able to build the support for the latter. The $handle should
also be something like a standard Perl IO::Handle object. The point here
is to avoid writing to and reading from a file. I think I don't even
have to possibility to write to a string .. maybe though a memory file yes.
Just thinking,
Ari
[1] http://geoinformatics.tkk.fi/doc/Geo-GDAL/html/
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Spatial Indexes for Memory Layers?
Curious if there's any way to create spatial indexes for in memory layers? This electronic communication and any attachments may contain confidential and proprietary information of DigitalGlobe, Inc. If you are not the intended recipient, or an agent or employee responsible for delivering this communication to the intended recipient, or if you have received this communication in error, please do not print, copy, retransmit, disseminate or otherwise use the information. Please indicate to the sender that you have received this communication in error, and delete the copy you received. DigitalGlobe reserves the right to monitor any electronic communication sent or received by its employees, agents or representatives. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Does SetSpatialFilter use spatial indexes (.qix) for shapefiles
Curious if the Shapefile driver uses .qix files if they're available when performing SetSpatialFitler. Thanks, -e This electronic communication and any attachments may contain confidential and proprietary information of DigitalGlobe, Inc. If you are not the intended recipient, or an agent or employee responsible for delivering this communication to the intended recipient, or if you have received this communication in error, please do not print, copy, retransmit, disseminate or otherwise use the information. Please indicate to the sender that you have received this communication in error, and delete the copy you received. DigitalGlobe reserves the right to monitor any electronic communication sent or received by its employees, agents or representatives. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Reading SRTM30 grids 'at distance'
Hi, I made a nice little tool for Mirone where one can very easily mosaic either several flavors of SRTM grids or satellite images from Bing servers. My question is about the SRTM30 grids (30 arc minutes) that are available here (SRTM plus) ftp://topex.ucsd.edu/pub/srtm30_plus/srtm30/data/ which I would like to be able to access directly with the vsicurl mechanism. The trouble in this case is that those grids are raw files without any header file. When we have them on disk the simple solution is to create a esri .hdr header from the information extracted from the file name. However, this logic does not work for files seating in the Web because the file and the header won't be located next to each other. The same occurs if one has those files compressed. In this case the header file cannot be assumed to be stored inside the .zip file and the vsizip mechanism will fail for exactly the same reason. My question is than, if there is a mechanism to send the header info to the GDAL library and thus pretend that file and header leave side by side? Note that I want to do this programmatically so need for an already existing ready to use solution. Thanks Joaquim ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Does SetSpatialFilter use spatial indexes (.qix) for shapefiles
Le lundi 14 novembre 2011 18:17:38, Ethan Alpert a écrit : Curious if the Shapefile driver uses .qix files if they're available when performing SetSpatialFitler. Ethan, Quoting http://gdal.org/ogr/drv_shapefile.html : The spatial indexing uses the same .qix quadtree spatial index files that are used by UMN MapServer. [...]. Spatial indexing can accelerate spatially filtered passes through large datasets to pick out a small area quite dramatically. Best regards, Even ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Spatial Indexes for Memory Layers?
Le lundi 14 novembre 2011 18:10:51, Ethan Alpert a écrit : Curious if there's any way to create spatial indexes for in memory layers? Ethan No, they are not supported by the OGR Memory driver. But... if you use the very latest trunk with spatialite support, the OGR SQLite driver now supports the VSI virtual file API, which enable you to create a spatialite DB in /vsimem/foo.db for example and thus taking advantage of spatial index. Best regards, Even ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Reading SRTM30 grids 'at distance'
Joaquim, I can't think of a way to do this with an ESRI .hdr and raw file. However, you could create a VRT file for each tile with the .VRT file living locally, having the georeferencing and raw data layout and referring to the actual raw data via a /vsicurl filename. The VRT docs cover how to describe a raw file in VRT. Best regards, On Mon, Nov 14, 2011 at 9:23 AM, Joaquim Luis jl...@ualg.pt wrote: Hi, I made a nice little tool for Mirone where one can very easily mosaic either several flavors of SRTM grids or satellite images from Bing servers. My question is about the SRTM30 grids (30 arc minutes) that are available here (SRTM plus) ftp://topex.ucsd.edu/pub/srtm30_plus/srtm30/data/ which I would like to be able to access directly with the vsicurl mechanism. The trouble in this case is that those grids are raw files without any header file. When we have them on disk the simple solution is to create a esri .hdr header from the information extracted from the file name. However, this logic does not work for files seating in the Web because the file and the header won't be located next to each other. The same occurs if one has those files compressed. In this case the header file cannot be assumed to be stored inside the .zip file and the vsizip mechanism will fail for exactly the same reason. My question is than, if there is a mechanism to send the header info to the GDAL library and thus pretend that file and header leave side by side? Note that I want to do this programmatically so need for an already existing ready to use solution. Thanks Joaquim ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Reading SRTM30 grids 'at distance'
Le lundi 14 novembre 2011 18:23:23, Joaquim Luis a écrit : Hi, I made a nice little tool for Mirone where one can very easily mosaic either several flavors of SRTM grids or satellite images from Bing servers. My question is about the SRTM30 grids (30 arc minutes) that are available here (SRTM plus) ftp://topex.ucsd.edu/pub/srtm30_plus/srtm30/data/ which I would like to be able to access directly with the vsicurl mechanism. The trouble in this case is that those grids are raw files without any header file. When we have them on disk the simple solution is to create a esri .hdr header from the information extracted from the file name. However, this logic does not work for files seating in the Web because the file and the header won't be located next to each other. The same occurs if one has those files compressed. In this case the header file cannot be assumed to be stored inside the .zip file and the vsizip mechanism will fail for exactly the same reason. My question is than, if there is a mechanism to send the header info to the GDAL library and thus pretend that file and header leave side by side? Note that I want to do this programmatically so need for an already existing ready to use solution. One way to do this is to use the capability of VRT files to describe raw files ( http://www.gdal.org/gdal_vrttut.html ), that offer similar capabilities than the EHdr header. For e020n40.Bathymetry.srtm, a quick test shows that the following should do : VRTDataset rasterXSize=4800 rasterYSize=6000 SRSGEOGCS[quot;WGS 84quot;,DATUM[quot;WGS_1984quot;,SPHEROID[quot;WGS 84quot;,6378137,298.257223563,AUTHORITY[quot;EPSGquot;,quot;7030quot;]],AUTHORITY[quot;EPSGquot;,quot;6326quot;]],PRIMEM[quot;Greenwichquot;,0,AUTHORITY[quot;EPSGquot;,quot;8901quot;]],UNIT[quot;degreequot;,0.0174532925199433,AUTHORITY[quot;EPSGquot;,quot;9122quot;]],AUTHORITY[quot;EPSGquot;,quot;4326quot;]]/SRS GeoTransform20, 0.008, 0.0, 40, 0.0, -0.008/GeoTransform VRTRasterBand dataType=Int16 band=1 subClass=VRTRawRasterBand SourceFilename relativetoVRT=0/vsicurl/ftp://topex.ucsd.edu/pub/srtm30_plus/srtm30/data/e020n40.Bathymetry.srtm/SourceFilename ImageOffset0/ImageOffset PixelOffset2/PixelOffset LineOffset9600/LineOffset ByteOrderMSB/ByteOrder /VRTRasterBand /VRTDataset (I've attached it to avoid line wrapping problems) Thanks Joaquim ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev VRTDataset rasterXSize=4800 rasterYSize=6000 SRSGEOGCS[quot;WGS 84quot;,DATUM[quot;WGS_1984quot;,SPHEROID[quot;WGS 84quot;,6378137,298.257223563,AUTHORITY[quot;EPSGquot;,quot;7030quot;]],AUTHORITY[quot;EPSGquot;,quot;6326quot;]],PRIMEM[quot;Greenwichquot;,0,AUTHORITY[quot;EPSGquot;,quot;8901quot;]],UNIT[quot;degreequot;,0.0174532925199433,AUTHORITY[quot;EPSGquot;,quot;9122quot;]],AUTHORITY[quot;EPSGquot;,quot;4326quot;]]/SRS GeoTransform20, 0.008, 0.0, 40, 0.0, -0.008/GeoTransform VRTRasterBand dataType=Int16 band=1 subClass=VRTRawRasterBand SourceFilename relativetoVRT=0/vsicurl/ftp://topex.ucsd.edu/pub/srtm30_plus/srtm30/data/e020n40.Bathymetry.srtm/SourceFilename ImageOffset0/ImageOffset PixelOffset2/PixelOffset LineOffset9600/LineOffset ByteOrderMSB/ByteOrder /VRTRasterBand /VRTDataset ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Reading SRTM30 grids 'at distance'
Evan, Frank Thanks very much. I keep insisting on the esri .hdr because I have a function to do all the work but it's definitively time to write one to do the same for .vrt (and learn more about it a same time). Joaquim Le lundi 14 novembre 2011 18:23:23, Joaquim Luis a écrit : Hi, I made a nice little tool for Mirone where one can very easily mosaic either several flavors of SRTM grids or satellite images from Bing servers. My question is about the SRTM30 grids (30 arc minutes) that are available here (SRTM plus) ftp://topex.ucsd.edu/pub/srtm30_plus/srtm30/data/ which I would like to be able to access directly with the vsicurl mechanism. The trouble in this case is that those grids are raw files without any header file. When we have them on disk the simple solution is to create a esri .hdr header from the information extracted from the file name. However, this logic does not work for files seating in the Web because the file and the header won't be located next to each other. The same occurs if one has those files compressed. In this case the header file cannot be assumed to be stored inside the .zip file and the vsizip mechanism will fail for exactly the same reason. My question is than, if there is a mechanism to send the header info to the GDAL library and thus pretend that file and header leave side by side? Note that I want to do this programmatically so need for an already existing ready to use solution. One way to do this is to use the capability of VRT files to describe raw files ( http://www.gdal.org/gdal_vrttut.html ), that offer similar capabilities than the EHdr header. For e020n40.Bathymetry.srtm, a quick test shows that the following should do : VRTDataset rasterXSize=4800 rasterYSize=6000 SRSGEOGCS[quot;WGS 84quot;,DATUM[quot;WGS_1984quot;,SPHEROID[quot;WGS 84quot;,6378137,298.257223563,AUTHORITY[quot;EPSGquot;,quot;7030quot;]],AUTHORITY[quot;EPSGquot;,quot;6326quot;]],PRIMEM[quot;Greenwichquot;,0,AUTHORITY[quot;EPSGquot;,quot;8901quot;]],UNIT[quot;degreequot;,0.0174532925199433,AUTHORITY[quot;EPSGquot;,quot;9122quot;]],AUTHORITY[quot;EPSGquot;,quot;4326quot;]]/SRS GeoTransform20, 0.008, 0.0, 40, 0.0, -0.008/GeoTransform VRTRasterBand dataType=Int16 band=1 subClass=VRTRawRasterBand SourceFilename relativetoVRT=0/vsicurl/ftp://topex.ucsd.edu/pub/srtm30_plus/srtm30/data/e020n40.Bathymetry.srtm/SourceFilename ImageOffset0/ImageOffset PixelOffset2/PixelOffset LineOffset9600/LineOffset ByteOrderMSB/ByteOrder /VRTRasterBand /VRTDataset (I've attached it to avoid line wrapping problems) Thanks Joaquim ___ 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] GDAL GML driver and .xsd schema mapping
Jukka, It is not totally clear for me to what extent GDAL GML driver is utilising the .xsd schema if it is present. I have an example where the schema obviously in not utilised or respected. In the schema the nationalCode element is defined as /element element name=nationalCode type=string annotation documentation-- Definition --#13; Thematic identifier corresponding to the national administrative codes defined in each country.#13; In the GML file the nationalCode attribute has values which are strings but they contain always only numeric characters. The .gfs file created by GDAL is interpreting the attribute data type as Integer. PropertyDefn NamenationalCode/Name ElementPathnationalCode/ElementPath TypeInteger/Type /PropertyDefn In fact, the issuse is not with the nationalCode because OGR knows the string type. The issue is with the following elements, like inspireId whose type base:IdentifierPropertyType is not understood. When the XSD parser doesn't understand an element, it is preferable for it to completely give up, instead of only keeping the fields it understands and loosing the others one, which would lead to information loss. When the XSD parser fails, or the XSD doesn't exist, a full scan of the GML is triggered to make an auto-discovery of its structure that will be recorded in a .gfs file. Of course, as a side- effect, this auto-discovery cannot guess that a field should be considered as string when all values found in the file are in fact integers. Ogr2ogr conversion to other formats gives a correct data type for this attribute if I edit first manually the .gfs file to use String type for nationalCode. I would like to know if this is how it is planned to be and users just need to remember to correct all the strings-with-only-numeric-characters attribute types manually. Perhaps this behaviour has something to do with the data which is using an Inspire schema that cannot be totally converted into ogr model? Comments of ticket 4328 http://trac.osgeo.org/gdal/ticket/4328 especially http://trac.osgeo.org/gdal/changeset/23315 seem to suggest so. Yes, this schema is too complex for the OGR XSD parser (and beyond the capabilities of the parser itself, it doesn't feed into the Simple Feature model). The parser basically only understoods a subset of the possible schemas. It should match pretty much what is described as the Compliance level SF-0 of GML 3.1.1 simple features profile - OGC(R) 06-049r1 : http://portal.opengeospatial.org/files/?artifact_id=15201 Which, in a single sentence, basically means only simple fields with a single occurrence each. If that is a case, could it be possible to make ogr2ogr to print the message /* Too complex schema for us. Aborts parsing */ also on screen as a warning? Otherwise users can believe that the .xsd schema file is used even it is not. Hopefully the following should be enough : r23378 /trunk/gdal/ogr/ogrsf_frmts/gml/ogrgmldatasource.cpp: GML: add debug information to know if we use/generate .gfs file while there's a .xsd we ignore I'm not sure it is a good idea to make it more verbose than a debug trace. Best regards, Even ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] access attribute (non-spatial) data in .mdb with PGeo Driver
Hi all, On Windows, I'm trying to access non-spatial tables in an .mdb file. With --debug on I see that the absence of a 'GDB_GeomColumns' table is the problem. ogrinfo --debug on Surveys.mdb PGeo: EstablishSession(DRIVER=Microsoft Access Driver (*.mdb);DBQ=Surveys.mdb) ODBC: SQLDriverConnect(DRIVER=Microsoft Access Driver (*.mdb);DBQ=Surveys.mdb) PGEO: SELECT on GDB_GeomColumns fails, perhaps not a personal geodatabase? [Microsoft][ODBC Microsoft Access Driver] The Microsoft Jet database engine cann ot find the input table or query 'GDB_GeomColumns'. Make sure it exists and tha t its name is spelled correctly. ODBC: SQLDisconnect() I noticed this fairly recent commit, which seems to indicate that this is the desired behavior, http://trac.osgeo.org/gdal/changeset/21550 I was able to access the non-spatial attributes by making a 'GDB_GeomColumns' table and falsely populating it (and ignoring the missing 'GDB_SpatialRefs' table errors). TableName FieldName ShapeType ExtentLeft ExtentBottom ExtentRight ExtentTop IdxOriginX IdxOriginY IdxGridSize SRIDHasZHasM Survey Shape 4 7255394.59721669241841.239197335 7396378.9177745 524650.4612300040 0 141508.958339791 1 0 0 ogrinfo -so Surveys.mdb Survey ERROR 1: 'SELECT srtext FROM GDB_SpatialRefs WHERE srid = 1' failed. [Microsoft][ODBC Microsoft Access Driver] The Microsoft Jet database engine cann ot find the input table or query 'GDB_SpatialRefs'. Make sure it exists and tha t its name is spelled correctly. INFO: Open of `Surveys.mdb' using driver `PGeo' successful. Layer name: Survey Geometry: Unknown (any) Feature Count: 20790 Extent: (7255394.597217, 241841.239197) - (7396378.917775, 524650.461230) Layer SRS WKT: (unknown) Geometry Column = Shape DocumentName: String (25.0) SurveyDate: DateTime (19.0) ... If the general case requires a 'GDB_GeomColumns' table, could no 'GDB_GeomColumns' table be made a driver config option? I noticed that the new Access MDB driver, http://gdal.org/ogr/drv_mdb.html , does not require a GDB_GeomColumns table (tested on ubuntu 10.04 and gdal trunk). Thanks, Eli ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] access attribute (non-spatial) data in .mdb with PGeo Driver
Le lundi 14 novembre 2011 20:44:35, Eli Adam a écrit : Hi all, On Windows, I'm trying to access non-spatial tables in an .mdb file. With --debug on I see that the absence of a 'GDB_GeomColumns' table is the problem. ogrinfo --debug on Surveys.mdb PGeo: EstablishSession(DRIVER=Microsoft Access Driver (*.mdb);DBQ=Surveys.mdb) ODBC: SQLDriverConnect(DRIVER=Microsoft Access Driver (*.mdb);DBQ=Surveys.mdb) PGEO: SELECT on GDB_GeomColumns fails, perhaps not a personal geodatabase? [Microsoft][ODBC Microsoft Access Driver] The Microsoft Jet database engine cann ot find the input table or query 'GDB_GeomColumns'. Make sure it exists and tha t its name is spelled correctly. ODBC: SQLDisconnect() I noticed this fairly recent commit, which seems to indicate that this is the desired behavior, http://trac.osgeo.org/gdal/changeset/21550 I'm confused because if you get to the point of having the trace PGEO: SELECT on GDB_GeomColumns fails, perhaps not a personal geodatabase? it means that you got after the test of r21550 (which should have discared this mdb as having no GDB_GeomColumns table), so I highly suspect you are not using trunk version for this test. r21550 only enforces what existed before : the PGeo driver can only handle PGeo MDBs. The new test was introduced specifically to avoid the PGeo driver to try opening a MDB that should be recognized by the Geomedia driver (new in trunk). I was able to access the non-spatial attributes by making a 'GDB_GeomColumns' table and falsely populating it (and ignoring the missing 'GDB_SpatialRefs' table errors). TableName FieldName ShapeType ExtentLeft ExtentBottom ExtentRight ExtentTop IdxOriginX IdxOriginY IdxGridSize SRIDHasZHasM SurveyShape 4 7255394.59721669241841.239197335 7396378.9177745 524650.46 1230004 0 0 141508.9583397911 0 0 ogrinfo -so Surveys.mdb Survey ERROR 1: 'SELECT srtext FROM GDB_SpatialRefs WHERE srid = 1' failed. [Microsoft][ODBC Microsoft Access Driver] The Microsoft Jet database engine cann ot find the input table or query 'GDB_SpatialRefs'. Make sure it exists and tha t its name is spelled correctly. INFO: Open of `Surveys.mdb' using driver `PGeo' successful. Layer name: Survey Geometry: Unknown (any) Feature Count: 20790 Extent: (7255394.597217, 241841.239197) - (7396378.917775, 524650.461230) Layer SRS WKT: (unknown) Geometry Column = Shape DocumentName: String (25.0) SurveyDate: DateTime (19.0) ... If the general case requires a 'GDB_GeomColumns' table, could no 'GDB_GeomColumns' table be made a driver config option? Why not using the generic ODBC driver for that use case ? I noticed that the new Access MDB driver, http://gdal.org/ogr/drv_mdb.html , does not require a GDB_GeomColumns table (tested on ubuntu 10.04 and gdal trunk). Yes, it can understand PGeo MDBs, Geomedia MDBs and generic MDBs. Thanks, 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] access attribute (non-spatial) data in .mdb with PGeo Driver
Thanks Even. I'm confused because if you get to the point of having the trace PGEO: SELECT on GDB_GeomColumns fails, perhaps not a personal geodatabase? it means that you got after the test of r21550 (which should have discared this mdb as having no GDB_GeomColumns table), so I highly suspect you are not using trunk version for this test. Correct. I'm using an old OSGeo4W 1.8dev. Yes, I should have noticed that I was not using the results of that r21550. r21550 only enforces what existed before : the PGeo driver can only handle PGeo MDBs. The new test was introduced specifically to avoid the PGeo driver to try opening a MDB that should be recognized by the Geomedia driver (new in trunk). I confirmed that I don't get that trace with the gisinternals release-1600-gdal-mapserver (from about 2 weeks ago). I also checked with this before writing the list, but just checked that trunk also didn't open the file. I didn't redo the --debug on portion. Why not using the generic ODBC driver for that use case ? This is apparently what I should have been doing. I'll try that now. Thanks, Eli ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] autotests for specific formats in autotest/gcore folder???
Hi devs, I have noticed today that there are a few format-specific tests in the autotest/gcore folder: aaigrid_read.py bmp_read.py envi_read.py hdf4_read.py hfa_read.py pnm_read.py tiff_read.py aaigrid_write.py bmp_write.py gtiff_write.py hdf4_write.py hfa_write.py netcdf_write.py pnm_write.py tiff_write.py They should probably be in the autotest/gdrivers folder instead, right? Are they in the gcore folder for purely historic reasons or another reason? regards, Etienne ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] autotests for specific formats in autotest/gcore folder???
Etienne, This is partly a historical artifact, but it never seemed worth the disruption to move things around. Note that some of these test scripts are primarily intended to test core capabilities and they just happen to do it with particular formats. I think that applies to some of the hfa and tiff scripts. Best regards, On Mon, Nov 14, 2011 at 1:29 PM, Etienne Tourigny etourigny@gmail.com wrote: Hi devs, I have noticed today that there are a few format-specific tests in the autotest/gcore folder: aaigrid_read.py bmp_read.py envi_read.py hdf4_read.py hfa_read.py pnm_read.py tiff_read.py aaigrid_write.py bmp_write.py gtiff_write.py hdf4_write.py hfa_write.py netcdf_write.py pnm_write.py tiff_write.py They should probably be in the autotest/gdrivers folder instead, right? Are they in the gcore folder for purely historic reasons or another reason? regards, Etienne ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Re: GDAL GML driver and .xsd schema mapping
Even Rouault even.rouault at mines-paris.org writes: Jukka, Hopefully the following should be enough : r23378 /trunk/gdal/ogr/ogrsf_frmts/gml/ogrgmldatasource.cpp: GML: add debug information to know if we use/generate .gfs file while there's a .xsd we ignore I'm not sure it is a good idea to make it more verbose than a debug trace. Thanks, it will be enough for me. I am awaiting samples of other ready defined Inspire data products, they can be more painful than this authorative units dataset which has after all rather simple structure. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
