Re: [gdal-dev] Clipping multi-polygons shapefiles with Geometry.Intersection . Any help to fix out my method?
No idea about this issue?? Thanks for help ! -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/gdal-dev-Clipping-multi-polygons-shapefiles-with-Geometry-Intersection-Any-help-to-fix-out-my-method-tp6410874p6421682.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] ERDASJP2 Debug builds crash
All,
I have been trying to build GDAL with ECWJP2 support. I have built a
test program using exactly the same build environment (vc80) and flags
as the gdal default gdal build enviroment. In Debug builds in or out of
the debugger I experience a crash in the ERDAS (debug) dll on
GDALClose(). Below I include full details demonstrating the vanilla test
carried out.
If anyone could offer thoughts on what I might be doing wrong I would be
very grateful.
Emmet.
I build gdal 1.8 using nmake /f makefile.vc DEBUG=1 having set the ECW
variables in nmake.opt
--- BUILD EXTRACT FOLLOWS SHOWING 'Default' DEBUG BUILD --
D:\ThirdPartyBuilds\GDAL\yagb\gdal-1.8.0\frmtscd ecwnmake /nologo
/f makefile.vccd .. || exit 1
cl /nologo /MD /EHsc /Zi /W4 /D_CRT_SECURE_NO_DEPRECATE
/D_CRT_NONSTDC_NO_DEPRECATE /Fd..\..\gdal18.pdb /DDEBUG -I..\..\port
-I..\..\ogr -I..\..\gcore -I..\..\alg -I..\..\ogr\ogrsf_frmt
s -DHAVE_COMPRESS -DECWSDK_VERSION=41 -ID:\Program Files
(x86)\ERDAS\ERDAS ECWJP2 SDK Desktop Read-Write\include -ID:\Program
Files (x86)\ERDAS\ERDAS ECWJP2 SDK Desktop Read-Write\include/e
cw/api -ID:\Program Files (x86)\ERDAS\ERDAS ECWJP2 SDK Desktop
Read-Write\include/ecw/jp2 -ID:\Program Files (x86)\ERDAS\ERDAS
ECWJP2 SDK Desktop Read-Write\include/ecw/ecw -DFRMT_ecw -DOGR_
ENABLED /c ecwdataset.cpp
ecwdataset.cpp
cl /nologo /MD /EHsc /Zi /W4 /D_CRT_SECURE_NO_DEPRECATE
/D_CRT_NONSTDC_NO_DEPRECATE /Fd..\..\gdal18.pdb /DDEBUG -I..\..\port
-I..\..\ogr -I..\..\gcore -I..\..\alg -I..\..\ogr\ogrsf_frmt
s -DHAVE_COMPRESS -DECWSDK_VERSION=41 -ID:\Program Files
(x86)\ERDAS\ERDAS ECWJP2 SDK Desktop Read-Write\include -ID:\Program
Files (x86)\ERDAS\ERDAS ECWJP2 SDK Desktop Read-Write\include/e
cw/api -ID:\Program Files (x86)\ERDAS\ERDAS ECWJP2 SDK Desktop
Read-Write\include/ecw/jp2 -ID:\Program Files (x86)\ERDAS\ERDAS
ECWJP2 SDK Desktop Read-Write\include/ecw/ecw -DFRMT_ecw -DOGR_
ENABLED /c ecwcreatecopy.cpp
ecwcreatecopy.cpp
cl /nologo /MD /EHsc /Zi /W4 /D_CRT_SECURE_NO_DEPRECATE
/D_CRT_NONSTDC_NO_DEPRECATE /Fd..\..\gdal18.pdb /DDEBUG -I..\..\port
-I..\..\ogr -I..\..\gcore -I..\..\alg -I..\..\ogr\ogrsf_frmt
s -DHAVE_COMPRESS -DECWSDK_VERSION=41 -ID:\Program Files
(x86)\ERDAS\ERDAS ECWJP2 SDK Desktop Read-Write\include -ID:\Program
Files (x86)\ERDAS\ERDAS ECWJP2 SDK Desktop Read-Write\include/e
cw/api -ID:\Program Files (x86)\ERDAS\ERDAS ECWJP2 SDK Desktop
Read-Write\include/ecw/jp2 -ID:\Program Files (x86)\ERDAS\ERDAS
ECWJP2 SDK Desktop Read-Write\include/ecw/ecw -DFRMT_ecw -DOGR_
ENABLED /c jp2userbox.cpp
jp2userbox.cpp
xcopy /y /r /d /f *.obj ..\o
D:\ThirdPartyBuilds\GDAL\yagb\gdal-1.8.0\frmts\ecw\ecwcreatecopy.obj -
D:\ThirdPartyBuilds\GDAL\yagb\gdal-1.8.0\frmts\o\ecwcreatecopy.obj
D:\ThirdPartyBuilds\GDAL\yagb\gdal-1.8.0\frmts\ecw\ecwdataset.obj -
D:\ThirdPartyBuilds\GDAL\yagb\gdal-1.8.0\frmts\o\ecwdataset.obj
D:\ThirdPartyBuilds\GDAL\yagb\gdal-1.8.0\frmts\ecw\jp2userbox.obj -
D:\ThirdPartyBuilds\GDAL\yagb\gdal-1.8.0\frmts\o\jp2userbox.obj
...
lib /nologo /out:gdal.lib port\*.obj gcore\*.obj alg\*.obj
frmts\o\*.obj ogr\ogrsf_frmts\ogrsf_frmts.lib ogr\ogr.lib
ogrsf_frmts.lib(resolvexlinks.obj) : warning LNK4221: no public symbols
found; archive member will be inaccessible
link /nologo /dll /INCLUDE:_OGRFeatureStylePuller
/INCLUDE:_OSRValidate /INCLUDE:_OPTGetProjectionMethods
/INCLUDE:_OGR_G_GetPointCount /INCLUDE:_OGRRegisterAll
/INCLUDE:_GDALSimpleIm
ageWarp@36 /INCLUDE:_GDALReprojectImage@48
/INCLUDE:_GDALComputeMedianCutPCT@32 /INCLUDE:_GDALDitherRGB2PCT@28
/INCLUDE:_OCTNewCoordinateTransformation@8 port\*.obj gcore\*.obj
alg\*.obj frm
ts\o\*.obj ogr\ogrsf_frmts\ogrsf_frmts.lib ogr\ogr.lib
D:\Program Files (x86)\ERDAS\ERDAS ECWJP2 SDK Desktop
Read-Write\lib\vc80\win32\NCSEcw4d.lib D:\Program Files
(x86)\ERDAS\ERDAS
ECWJP2 SDK Desktop Read-Write\lib\vc80\win32\NCSUtil4d.lib D:\Program
Files (x86)\ERDAS\ERDAS ECWJP2 SDK Desktop
Read-Write\lib\vc80\win32\NCScnet4d.lib
odbc32.lib
odbccp32.lib user32.lib gcore\Version.res /out:gdal18.dll
/implib:gdal_i.lib /debug
--- BUILD EXTRACT END --
I then built a simple test app:
#include cpl_conv.h
#include gdal.h
#include gdal_priv.h
#include windows.h
#include iostream
int main ()
{
// DebugBreak();
unsigned int x_size = 100;
unsigned int y_size = 150;
unsigned int xstep = 1;
unsigned int pstep = 1;
unsigned int nplanes = 1;
unsigned int ystep = x_size * xstep;
void * data = malloc( y_size * ystep );
memset( data, 128, y_size * ystep );
// OEM License code for ERDAS ECW JPEG2000 compression capability
CPLSetConfigOption( ECW_ENCODE_COMPANY, );
CPLSetConfigOption( ECW_ENCODE_KEY, );
GDALAllRegister();
GDALDriver * pDriver = GetGDALDriverManager()-GetDriverByName(
JP2ECW );
if ( pDriver )
{
std::cout
RE: [gdal-dev] Table Names (FGDB)
Paul, The schema.table is the most similar to the structure of the fgdb, but may be unwanted complexity. Can this be an option? Like yes, consider the dataset name? Or no, discard dataset name. I can see myself in both situations... Is the driver read only? If not, what will happen when you try the reverse? From PgSql to fgdb? Duarte -Mensagem original- De: Paul Ramsey [mailto:pram...@cleverelephant.ca] Enviada: segunda-feira, 30 de Maio de 2011 22:47 Para: gdal-dev@lists.osgeo.org Assunto: [gdal-dev] Table Names (FGDB) So, my goal is to map information from FGDB to PostGIS and as much fidelity as possible. FGDB includes a class called Feature Dataset which is basically a folder that holds Feature Class objects, which map directly to OGR layers. So the Feature Dataset then acts a good deal like a schema in PostGIS. I've noticed that the PgSQL driver supports a SCHEMA keyword to allow you to write to a schema without schema-qualified table names, and that it also notices when table names are schema qualified and puts them in the appropriate place. So the name of a layer read from a schema would show up in OGR as schemaname.tablename. In FGDB, we have the path of a Feature Class or Table, which looks like this \FeatureDataset\FeatureClass. Similar to the schema qualification, yet different. As it stands right now, the FeatureDataset portion of the path is discarded in the public API, so that the OGR layer name is just the FeatureClass, with no reference to the FeatureDataset. That makes it hard to create a mapping from FGDB (\FeatureDataset\FeatureClass) to PostGIS (FeatureDataset.FeatureClass). The FGDB implementation currently returns GeoDatabase.GetQueryName() as the layer name, which Gets the query name (the name to use in SQL statements) of a table based on its path. If it returned the path name, then the FeatureDataset qualification information could be preserved in other contexts. On the other hand, perhaps the QueryName is more useful to more users than the path? It looks like the QueryName is expected to be unique, so probably FeatureClass and Table names have to be unique regardless of what FeatureDataset they appear in (true?). So my options are: (a) - change the current OGR layer name to the path name (b) - change the current OGR layer name to a schema.table analogue and handle appropriately (c) - leave the current OGR layer name as is (tablename regardless of containing folders) and make a FGDB-only method for accessing the pathname for my particular purposes Preferences? P. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ERDASJP2 Debug builds crash
On 11-05-31 07:20 AM, Emmet Spier wrote: All, I have been trying to build GDAL with ECWJP2 support. I have built a test program using exactly the same build environment (vc80) and flags as the gdal default gdal build enviroment. In Debug builds in or out of the debugger I experience a crash in the ERDAS (debug) dll on GDALClose(). Below I include full details demonstrating the vanilla test carried out. If anyone could offer thoughts on what I might be doing wrong I would be very grateful. Emmet. I build gdal 1.8 using nmake /f makefile.vc DEBUG=1 having set the ECW variables in nmake.opt --- BUILD EXTRACT FOLLOWS SHOWING 'Default' DEBUG BUILD -- D:\ThirdPartyBuilds\GDAL\yagb\gdal-1.8.0\frmtscd ecw nmake /nologo /f makefile.vc cd .. || exit 1 cl /nologo /MD /EHsc /Zi /W4 /D_CRT_SECURE_NO_DEPRECATE /D_CRT_NONSTDC_NO_DEPRECATE /Fd..\..\gdal18.pdb /DDEBUG -I..\..\port -I..\..\ogr -I..\..\gcore -I..\..\alg -I..\..\ogr\ogrsf_frmt Emmet, To the best of my knowledge adding DEBUG=1 to the build does not use the windows debug runtime, it just builds with /Zi (turn on debug information). So I presume the runtime choices are not compatible with a debug runtime build of the ECW SDK. I normally do not build GDAL with the debug runtime but if you really want to you are likely going to have adjust the flags yourself. 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] creating overview image wit gdaladdo
Hello, I am trying to create an overview image with gdaladdo and tried out different resampling parameter. My results looks fine on large scale, but zooming out (small scale) the image looks really poor. What I want to to achieve or reproduce is an effect like in ArcMap. Here embedding an black and white image and enabling the 'create Pyramids' option, it generates a really smooth image on small scale. Any idea or suggestion how to achieve this effect? Or is this an special ArcMap effect? Thanks for any suggestions and best regards, Toni Pignataro ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Clipping multi-polygons shapefiles with Geometry.Intersection . Any help to fix out my method?
It may help to supply a small test dataset that causes the problem. Best Regards, Brent Fraser On 5/31/2011 1:28 AM, hajer wrote: No idea about this issue?? Thanks for help ! -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/gdal-dev-Clipping-multi-polygons-shapefiles-with-Geometry-Intersection-Any-help-to-fix-out-my-method-tp6410874p6421682.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 mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] creating overview image wit gdaladdo
You can find for comparison here an image with my result: http://wheregroup.com/de/system/files/arcmapp_vs_gdaladdo.png Am 31.05.2011 15:29, schrieb Toni Pignataro: Hello, I am trying to create an overview image with gdaladdo and tried out different resampling parameter. My results looks fine on large scale, but zooming out (small scale) the image looks really poor. What I want to to achieve or reproduce is an effect like in ArcMap. Here embedding an black and white image and enabling the 'create Pyramids' option, it generates a really smooth image on small scale. Any idea or suggestion how to achieve this effect? Or is this an special ArcMap effect? Thanks for any suggestions and best regards, Toni Pignataro ___ 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] creating overview image wit gdaladdo
On 11-05-31 09:29 AM, Toni Pignataro wrote: Hello, I am trying to create an overview image with gdaladdo and tried out different resampling parameter. My results looks fine on large scale, but zooming out (small scale) the image looks really poor. What I want to to achieve or reproduce is an effect like in ArcMap. Here embedding an black and white image and enabling the 'create Pyramids' option, it generates a really smooth image on small scale. Any idea or suggestion how to achieve this effect? Or is this an special ArcMap effect? Toni, Is your base image a 1bit black and white image? If so, you might want to try AVERAGE_BIT2GRAYSCALE as the resampling algorithm. This is a special algorithm (implemented for ArcGIS) that produces greyscale overviews for one 1bit black and white images. Note that not all applications will handle the situation of greyscale overviews on a 1 bit base image gracefully. 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] Table Names (FGDB)
This is why I'm looking for guidance from the OGR experts... what layer name styles work best for interoperation? If I emit schema.table layers on read, will apps be happy or sad? The driver is moving towards read/write. I will have no trouble dealing with schema.table names as I can just map them to \FeatureDataset\FeatureClass under the covers, and create new FeatureDataset folders as necessary. P. On Tue, May 31, 2011 at 5:05 AM, Duarte Carreira dcarre...@edia.pt wrote: Paul, The schema.table is the most similar to the structure of the fgdb, but may be unwanted complexity. Can this be an option? Like yes, consider the dataset name? Or no, discard dataset name. I can see myself in both situations... Is the driver read only? If not, what will happen when you try the reverse? From PgSql to fgdb? Duarte -Mensagem original- De: Paul Ramsey [mailto:pram...@cleverelephant.ca] Enviada: segunda-feira, 30 de Maio de 2011 22:47 Para: gdal-dev@lists.osgeo.org Assunto: [gdal-dev] Table Names (FGDB) So, my goal is to map information from FGDB to PostGIS and as much fidelity as possible. FGDB includes a class called Feature Dataset which is basically a folder that holds Feature Class objects, which map directly to OGR layers. So the Feature Dataset then acts a good deal like a schema in PostGIS. I've noticed that the PgSQL driver supports a SCHEMA keyword to allow you to write to a schema without schema-qualified table names, and that it also notices when table names are schema qualified and puts them in the appropriate place. So the name of a layer read from a schema would show up in OGR as schemaname.tablename. In FGDB, we have the path of a Feature Class or Table, which looks like this \FeatureDataset\FeatureClass. Similar to the schema qualification, yet different. As it stands right now, the FeatureDataset portion of the path is discarded in the public API, so that the OGR layer name is just the FeatureClass, with no reference to the FeatureDataset. That makes it hard to create a mapping from FGDB (\FeatureDataset\FeatureClass) to PostGIS (FeatureDataset.FeatureClass). The FGDB implementation currently returns GeoDatabase.GetQueryName() as the layer name, which Gets the query name (the name to use in SQL statements) of a table based on its path. If it returned the path name, then the FeatureDataset qualification information could be preserved in other contexts. On the other hand, perhaps the QueryName is more useful to more users than the path? It looks like the QueryName is expected to be unique, so probably FeatureClass and Table names have to be unique regardless of what FeatureDataset they appear in (true?). So my options are: (a) - change the current OGR layer name to the path name (b) - change the current OGR layer name to a schema.table analogue and handle appropriately (c) - leave the current OGR layer name as is (tablename regardless of containing folders) and make a FGDB-only method for accessing the pathname for my particular purposes Preferences? P. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Table Names (FGDB)
Paul, PgSql is not the only driver that use the schema.table notation. I see that OGR's MSSQLSpatial driver too uses it too. So there won't be anything new. On the other hand, the '\' separator could lead to some confusion with escaping in some situations. On Tue, May 31, 2011 at 10:13 PM, Paul Ramsey pram...@cleverelephant.cawrote: This is why I'm looking for guidance from the OGR experts... what layer name styles work best for interoperation? If I emit schema.table layers on read, will apps be happy or sad? The driver is moving towards read/write. I will have no trouble dealing with schema.table names as I can just map them to \FeatureDataset\FeatureClass under the covers, and create new FeatureDataset folders as necessary. P. On Tue, May 31, 2011 at 5:05 AM, Duarte Carreira dcarre...@edia.pt wrote: Paul, The schema.table is the most similar to the structure of the fgdb, but may be unwanted complexity. Can this be an option? Like yes, consider the dataset name? Or no, discard dataset name. I can see myself in both situations... Is the driver read only? If not, what will happen when you try the reverse? From PgSql to fgdb? Duarte -Mensagem original- De: Paul Ramsey [mailto:pram...@cleverelephant.ca] Enviada: segunda-feira, 30 de Maio de 2011 22:47 Para: gdal-dev@lists.osgeo.org Assunto: [gdal-dev] Table Names (FGDB) So, my goal is to map information from FGDB to PostGIS and as much fidelity as possible. FGDB includes a class called Feature Dataset which is basically a folder that holds Feature Class objects, which map directly to OGR layers. So the Feature Dataset then acts a good deal like a schema in PostGIS. I've noticed that the PgSQL driver supports a SCHEMA keyword to allow you to write to a schema without schema-qualified table names, and that it also notices when table names are schema qualified and puts them in the appropriate place. So the name of a layer read from a schema would show up in OGR as schemaname.tablename. In FGDB, we have the path of a Feature Class or Table, which looks like this \FeatureDataset\FeatureClass. Similar to the schema qualification, yet different. As it stands right now, the FeatureDataset portion of the path is discarded in the public API, so that the OGR layer name is just the FeatureClass, with no reference to the FeatureDataset. That makes it hard to create a mapping from FGDB (\FeatureDataset\FeatureClass) to PostGIS (FeatureDataset.FeatureClass). The FGDB implementation currently returns GeoDatabase.GetQueryName() as the layer name, which Gets the query name (the name to use in SQL statements) of a table based on its path. If it returned the path name, then the FeatureDataset qualification information could be preserved in other contexts. On the other hand, perhaps the QueryName is more useful to more users than the path? It looks like the QueryName is expected to be unique, so probably FeatureClass and Table names have to be unique regardless of what FeatureDataset they appear in (true?). So my options are: (a) - change the current OGR layer name to the path name (b) - change the current OGR layer name to a schema.table analogue and handle appropriately (c) - leave the current OGR layer name as is (tablename regardless of containing folders) and make a FGDB-only method for accessing the pathname for my particular purposes Preferences? P. ___ 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
RE: [gdal-dev] Table Names (FGDB)
Well, I'm no expert!! As far as applications go, the few I use *had* problems with schemas other than public, but I think this has been worked out for some time now. So I think schemas are well supported - but it may be worthwhile asking qgis and gvsig how they are faring with these today... I can hook up some people from qgis to this thread (if they're not following already...). Duarte -Mensagem original- De: Paul Ramsey [mailto:pram...@cleverelephant.ca] Enviada: terça-feira, 31 de Maio de 2011 17:43 Para: Duarte Carreira Cc: gdal-dev@lists.osgeo.org Assunto: Re: [gdal-dev] Table Names (FGDB) This is why I'm looking for guidance from the OGR experts... what layer name styles work best for interoperation? If I emit schema.table layers on read, will apps be happy or sad? The driver is moving towards read/write. I will have no trouble dealing with schema.table names as I can just map them to \FeatureDataset\FeatureClass under the covers, and create new FeatureDataset folders as necessary. P. On Tue, May 31, 2011 at 5:05 AM, Duarte Carreira dcarre...@edia.pt wrote: Paul, The schema.table is the most similar to the structure of the fgdb, but may be unwanted complexity. Can this be an option? Like yes, consider the dataset name? Or no, discard dataset name. I can see myself in both situations... Is the driver read only? If not, what will happen when you try the reverse? From PgSql to fgdb? Duarte -Mensagem original- De: Paul Ramsey [mailto:pram...@cleverelephant.ca] Enviada: segunda-feira, 30 de Maio de 2011 22:47 Para: gdal-dev@lists.osgeo.org Assunto: [gdal-dev] Table Names (FGDB) So, my goal is to map information from FGDB to PostGIS and as much fidelity as possible. FGDB includes a class called Feature Dataset which is basically a folder that holds Feature Class objects, which map directly to OGR layers. So the Feature Dataset then acts a good deal like a schema in PostGIS. I've noticed that the PgSQL driver supports a SCHEMA keyword to allow you to write to a schema without schema-qualified table names, and that it also notices when table names are schema qualified and puts them in the appropriate place. So the name of a layer read from a schema would show up in OGR as schemaname.tablename. In FGDB, we have the path of a Feature Class or Table, which looks like this \FeatureDataset\FeatureClass. Similar to the schema qualification, yet different. As it stands right now, the FeatureDataset portion of the path is discarded in the public API, so that the OGR layer name is just the FeatureClass, with no reference to the FeatureDataset. That makes it hard to create a mapping from FGDB (\FeatureDataset\FeatureClass) to PostGIS (FeatureDataset.FeatureClass). The FGDB implementation currently returns GeoDatabase.GetQueryName() as the layer name, which Gets the query name (the name to use in SQL statements) of a table based on its path. If it returned the path name, then the FeatureDataset qualification information could be preserved in other contexts. On the other hand, perhaps the QueryName is more useful to more users than the path? It looks like the QueryName is expected to be unique, so probably FeatureClass and Table names have to be unique regardless of what FeatureDataset they appear in (true?). So my options are: (a) - change the current OGR layer name to the path name (b) - change the current OGR layer name to a schema.table analogue and handle appropriately (c) - leave the current OGR layer name as is (tablename regardless of containing folders) and make a FGDB-only method for accessing the pathname for my particular purposes Preferences? P. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Convert from CA83-VF (EPSG 2229) to WGS84 (EPSG 4326) using gdaltransform
On 05/31/11 21:23, kavinmehta wrote: Hi, I would like to convert a shape file from EPSG 2229 to EPSG 4326 but am not too sure how to do this using gdaltransform and running it from the command line? gdaltransform -s_srs c:\xyz\oldfile.shp -t_srs c:\xyz\newfile.shp but it did not work. Hi, The appropriate utility to reproject shapefiles is ogr2ogr : http://www.gdal.org/ogr2ogr.html Jean-Claude ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Re: Convert from CA83-VF (EPSG 2229) to WGS84 (EPSG 4326) using gdaltransform
Thanks Jean-Claude. I ran the following command: ogr2ogr -f ESRI Shapefile -overwrite C:/mapdata/ABC.shp C:/mapdata/ABC.shp -T_SRS EPSG:4326 and got similar error: ERROR 4: Unable to open EPSG support file gcs.csv. Try setting the GDAL_DATA environment variable to point to the directory containing EPSG csv files. Failed to process SRS definition: EPSG:4326 How do i say this is my input and this is my output file? if i give an o/p file name in the above command then it says it does not exist, which is correct because i want it to create it. hence i gave the same file name with an overwrite command but it did not work either. Thanks for your help. Kavin -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Convert-from-CA83-VF-EPSG-2229-to-WGS84-EPSG-4326-using-gdaltransform-tp6424186p6424310.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] Table Names (FGDB)
Le mardi 31 mai 2011 18:43:15, Paul Ramsey a écrit : This is why I'm looking for guidance from the OGR experts... what layer name styles work best for interoperation? If I emit schema.table layers on read, will apps be happy or sad? Not having followed the whole discussion and not sure to really understand the FGDB concepts, I don't think it would be very hard to propose a configuration option/environement variable to get the layer names reported as fully qualified or just the table names. The driver is moving towards read/write. I will have no trouble dealing with schema.table names as I can just map them to \FeatureDataset\FeatureClass under the covers, and create new FeatureDataset folders as necessary. P. On Tue, May 31, 2011 at 5:05 AM, Duarte Carreira dcarre...@edia.pt wrote: Paul, The schema.table is the most similar to the structure of the fgdb, but may be unwanted complexity. Can this be an option? Like yes, consider the dataset name? Or no, discard dataset name. I can see myself in both situations... Is the driver read only? If not, what will happen when you try the reverse? From PgSql to fgdb? Duarte -Mensagem original- De: Paul Ramsey [mailto:pram...@cleverelephant.ca] Enviada: segunda-feira, 30 de Maio de 2011 22:47 Para: gdal-dev@lists.osgeo.org Assunto: [gdal-dev] Table Names (FGDB) So, my goal is to map information from FGDB to PostGIS and as much fidelity as possible. FGDB includes a class called Feature Dataset which is basically a folder that holds Feature Class objects, which map directly to OGR layers. So the Feature Dataset then acts a good deal like a schema in PostGIS. I've noticed that the PgSQL driver supports a SCHEMA keyword to allow you to write to a schema without schema-qualified table names, and that it also notices when table names are schema qualified and puts them in the appropriate place. So the name of a layer read from a schema would show up in OGR as schemaname.tablename. In FGDB, we have the path of a Feature Class or Table, which looks like this \FeatureDataset\FeatureClass. Similar to the schema qualification, yet different. As it stands right now, the FeatureDataset portion of the path is discarded in the public API, so that the OGR layer name is just the FeatureClass, with no reference to the FeatureDataset. That makes it hard to create a mapping from FGDB (\FeatureDataset\FeatureClass) to PostGIS (FeatureDataset.FeatureClass). The FGDB implementation currently returns GeoDatabase.GetQueryName() as the layer name, which Gets the query name (the name to use in SQL statements) of a table based on its path. If it returned the path name, then the FeatureDataset qualification information could be preserved in other contexts. On the other hand, perhaps the QueryName is more useful to more users than the path? It looks like the QueryName is expected to be unique, so probably FeatureClass and Table names have to be unique regardless of what FeatureDataset they appear in (true?). So my options are: (a) - change the current OGR layer name to the path name (b) - change the current OGR layer name to a schema.table analogue and handle appropriately (c) - leave the current OGR layer name as is (tablename regardless of containing folders) and make a FGDB-only method for accessing the pathname for my particular purposes Preferences? P. ___ 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] Table Names (FGDB)
Yes, the magic of the configuration option... that makes much sense. So by default we will emit simple layer names, but we can be configured to emit qualified names. On Tue, May 31, 2011 at 1:23 PM, Even Rouault even.roua...@mines-paris.org wrote: Le mardi 31 mai 2011 18:43:15, Paul Ramsey a écrit : This is why I'm looking for guidance from the OGR experts... what layer name styles work best for interoperation? If I emit schema.table layers on read, will apps be happy or sad? Not having followed the whole discussion and not sure to really understand the FGDB concepts, I don't think it would be very hard to propose a configuration option/environement variable to get the layer names reported as fully qualified or just the table names. The driver is moving towards read/write. I will have no trouble dealing with schema.table names as I can just map them to \FeatureDataset\FeatureClass under the covers, and create new FeatureDataset folders as necessary. P. On Tue, May 31, 2011 at 5:05 AM, Duarte Carreira dcarre...@edia.pt wrote: Paul, The schema.table is the most similar to the structure of the fgdb, but may be unwanted complexity. Can this be an option? Like yes, consider the dataset name? Or no, discard dataset name. I can see myself in both situations... Is the driver read only? If not, what will happen when you try the reverse? From PgSql to fgdb? Duarte -Mensagem original- De: Paul Ramsey [mailto:pram...@cleverelephant.ca] Enviada: segunda-feira, 30 de Maio de 2011 22:47 Para: gdal-dev@lists.osgeo.org Assunto: [gdal-dev] Table Names (FGDB) So, my goal is to map information from FGDB to PostGIS and as much fidelity as possible. FGDB includes a class called Feature Dataset which is basically a folder that holds Feature Class objects, which map directly to OGR layers. So the Feature Dataset then acts a good deal like a schema in PostGIS. I've noticed that the PgSQL driver supports a SCHEMA keyword to allow you to write to a schema without schema-qualified table names, and that it also notices when table names are schema qualified and puts them in the appropriate place. So the name of a layer read from a schema would show up in OGR as schemaname.tablename. In FGDB, we have the path of a Feature Class or Table, which looks like this \FeatureDataset\FeatureClass. Similar to the schema qualification, yet different. As it stands right now, the FeatureDataset portion of the path is discarded in the public API, so that the OGR layer name is just the FeatureClass, with no reference to the FeatureDataset. That makes it hard to create a mapping from FGDB (\FeatureDataset\FeatureClass) to PostGIS (FeatureDataset.FeatureClass). The FGDB implementation currently returns GeoDatabase.GetQueryName() as the layer name, which Gets the query name (the name to use in SQL statements) of a table based on its path. If it returned the path name, then the FeatureDataset qualification information could be preserved in other contexts. On the other hand, perhaps the QueryName is more useful to more users than the path? It looks like the QueryName is expected to be unique, so probably FeatureClass and Table names have to be unique regardless of what FeatureDataset they appear in (true?). So my options are: (a) - change the current OGR layer name to the path name (b) - change the current OGR layer name to a schema.table analogue and handle appropriately (c) - leave the current OGR layer name as is (tablename regardless of containing folders) and make a FGDB-only method for accessing the pathname for my particular purposes Preferences? P. ___ 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: Convert from CA83-VF (EPSG 2229) to WGS84 (EPSG 4326) using gdaltransform
On 11-05-31 04:06 PM, kavinmehta wrote: Thanks Jean-Claude. I ran the following command: ogr2ogr -f ESRI Shapefile -overwrite C:/mapdata/ABC.shp C:/mapdata/ABC.shp -T_SRS EPSG:4326 and got similar error: ERROR 4: Unable to open EPSG support file gcs.csv. Try setting the GDAL_DATA environment variable to point to the directory containing EPSG csv files. Failed to process SRS definition: EPSG:4326 How do i say this is my input and this is my output file? if i give an o/p file name in the above command then it says it does not exist, which is correct because i want it to create it. hence i gave the same file name with an overwrite command but it did not work either. Kavin, You cannot do update in place the way you want with ogr2ogr. I'm afraid you will need to transform your features into a new shapefile. 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: Convert from CA83-VF (EPSG 2229) to WGS84 (EPSG 4326) using gdaltransform
Thanks Frank. Would you know how to do it? i.e. what command to use to convert a shape file from (EPSG 2229) to (EPSG 4326). I am having a hard time doing it thru ogr2ogr however i can easily do this in FME Desktop tool which uses ogr2ogr internally. Thanks, kavin Mehta. -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Convert-from-CA83-VF-EPSG-2229-to-WGS84-EPSG-4326-using-gdaltransform-tp6424186p6424722.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: Convert from CA83-VF (EPSG 2229) to WGS84 (EPSG 4326) using gdaltransform
On 11-05-31 05:51 PM, kavinmehta wrote: Thanks Frank. Would you know how to do it? i.e. what command to use to convert a shape file from (EPSG 2229) to (EPSG 4326). I am having a hard time doing it thru ogr2ogr however i can easily do this in FME Desktop tool which uses ogr2ogr internally. Kavin, Something like: ogr2ogr -t_srs EPSG:4326 -s_srs EPSG:2229 out.shp in.shp If the in.shp has a properly defined in.prj it will not be necessary to use the -s_srs switch to set the source coordinate system. 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
