Re: [gdal-dev] MSSQL Spatial and 3D issue
Thanks for that...I tried all different formats and looked into your changes. Could not retrieve my Z coordinate using wkb format because you created a new geometry format called *wkbzm*. Please update the doc (http://www.gdal.org/ogr/drv_mssqlspatial.html) and don't forget to specify that wkbzm is only available for SQL Server 2012: AsBinaryZM() does not exist in sql server 2008 see error thrown below: Could not find method 'AsBinaryZM' for type 'Microsoft.SqlServer.Types.SqlGeometry' in assembly 'Microsoft.SqlServer.Types' -- View this message in context: http://osgeo-org.1560.n6.nabble.com/gdal-dev-MSSQL-Spatial-and-3D-issue-tp4892552p5019794.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] Cannot read UTM Ozi .map file
On 29/11/2012 23:32, Nik Sands wrote: > Thanks for the reply. Firstly, it did resolve my problem, so thanks very > much for this information. > > However, I don't get that warning with gdalinfo . You have to use the debug switch (look at the command I used in my previous post). ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Cannot read UTM Ozi .map file
Thanks for the reply. Firstly, it did resolve my problem, so thanks very much for this information. However, I don't get that warning with gdalinfo (see below). But I set the environment variable in my code, and it did resolve the problem for me there which is all that matters, I guess. :-) I'm curious though, how does the quality of an image affect this? I had assumed that transforms would work on on pixel x,y coordinates irrespective of the colour values of those pixels. Anyhow, thanks again for your help. Much appreciated. Cheers, Nik. -- $ env | grep OZI $ gdalinfo Cradle\ Mountain_ozf.map Driver: OZI/OziExplorer Image File Files: Cradle Mountain_ozf.map Size is 6535, 11880 Coordinate System is: PROJCS["UTM Zone 55, Southern Hemisphere", GEOGCS["GDA94", DATUM["Geocentric_Datum_of_Australia_1994", SPHEROID["GRS 1980",6378137,298.257222101, AUTHORITY["EPSG","7019"]], TOWGS84[0,0,0,0,0,0,0], AUTHORITY["EPSG","6283"]], PRIMEM["Greenwich",0, AUTHORITY["EPSG","8901"]], UNIT["degree",0.0174532925199433, AUTHORITY["EPSG","9122"]], ... ... ... -- On 29/11/2012, at 10:08 PM, Jean-Claude Repetto wrote: > Le 28/11/2012 22:54, Nik Sands a écrit : > >> After applying the suggested patch, it no longer errors out in the same way, >> however, I now get another error just a little further on in my code. >> >> - >> Failed to get geo-transform (error 3) for file: Cradle Mountain_ozf.map >> - >> >> I'm afraid this is a bit beyond me, so if you can help, I'd be very grateful. > > Did you notice that gdalinfo reports the same error ? > > $ gdalinfo --debug on -noct Cradle\ Mountain_ozf.map > GDAL: GDALLoadOziMapFile(Cradle Mountain_ozf.map) found file, wasn't able to > derive a first order geotransform. Using points as GCPs. > GDAL: GDALOpen(Cradle Mountain_ozf.map, this=0x155a4a0) succeeds as OZI. > Driver: OZI/OziExplorer Image File > GDAL: GDALDefaultOverviews::OverviewScan() > Files: Cradle Mountain_ozf.map > Size is 6535, 11880 > Coordinate System is `' > GCP Projection = > PROJCS["UTM Zone 55, Southern Hemisphere", >GEOGCS["GDA94", >DATUM["Geocentric_Datum_of_Australia_1994", >SPHEROID["GRS 1980",6378137,298.257222101, >AUTHORITY["EPSG","7019"]], >TOWGS84[0,0,0,0,0,0,0], >AUTHORITY["EPSG","6283"]], >PRIMEM["Greenwich",0, >AUTHORITY["EPSG","8901"]], >UNIT["degree",0.0174532925199433, >AUTHORITY["EPSG","9122"]], >AUTHORITY["EPSG","4283"]], >PROJECTION["Transverse_Mercator"], >PARAMETER["latitude_of_origin",0], >PARAMETER["central_meridian",147], >PARAMETER["scale_factor",0.9996], >PARAMETER["false_easting",50], >PARAMETER["false_northing",1000], >UNIT["Meter",1]] > GCP[ 0]: Id=, Info= > (749,50) -> (41,5397000,0) > GCP[ 1]: Id=, Info= > (4697,38) -> (415000,5397000,0) > GCP[ 2]: Id=, Info= > (4668,11128) -> (415000,5383000,0) > GCP[ 3]: Id=, Info= > (757,11164) -> (41,5383000,0) > GCP[ 4]: Id=, Info= > (1532,5600) -> (411000,539,0) > GCP[ 5]: Id=, Info= > (3112,1611) -> (413000,5395000,0) > GCP[ 6]: Id=, Info= > (3894,7962) -> (414000,5387000,0) > GCP[ 7]: Id=, Info= > (3890,4794) -> (414000,5391000,0) > GCP[ 8]: Id=, Info= > (2318,9563) -> (412000,5385000,0) > Corner Coordinates: > Upper Left (0.0,0.0) > Lower Left (0.0,11880.0) > Upper Right ( 6535.0,0.0) > Lower Right ( 6535.0,11880.0) > Center ( 3267.5, 5940.0) > Band 1 Block=64x64 Type=Byte, ColorInterp=Palette > Overviews: 1634x2970, 654x1188, 327x594, 163x297, 65x119 > Color Table (RGB with 256 entries) > GDAL: GDALClose(Cradle Mountain_ozf.map, this=0x155a4a0) > > > This is because the quality of the scan is very bad. Look at the text "No > Camping Allowed", that appears almost twice. You can ask GDAL to ignore the > problem by setting the environment variable OZI_APPROX_GEOTRANSFORM to the > value YES (In this case, you can drop the patch I sent you yesterday) : > > $ OZI_APPROX_GEOTRANSFORM=YES gdalinfo -noct Cradle\ Mountain_ozf.map Driver: > OZI/OziExplorer Image File > Files: Cradle Mountain_ozf.map > Size is 6535, 11880 > Coordinate System is: > PROJCS["UTM Zone 55, Southern Hemisphere", >GEOGCS["GDA94", >DATUM["Geocentric_Datum_of_Australia_1994", >SPHEROID["GRS 1980",6378137,298.257222101, >AUTHORITY["EPSG","7019"]], >TOWGS84[0,0,0,0,0,0,0], >AUTHORITY["EPSG","6283"]], >PRIMEM["Greenwich",0, >AUTHORITY["EPSG","8901"]], >UNIT["degree",0.0174532925199433, >AUTHORITY["EPSG","9122"]], >AUTHORITY["EPSG","4283"]], >
Re: [gdal-dev] 64bit integers
Le jeudi 29 novembre 2012 23:23:44, Jeremy Palmer a écrit : > so just to confirm 64bit integers can not be implemented before 2.X or > 1.XX? I think (hope) that 1.10 will be the last of the 1.X series. Implementing 64bit integer involves ABI changes, so qualifies for 2.0. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] 64bit integers
so just to confirm 64bit integers can not be implemented before 2.X or 1.XX? - Original Message - From: Even Rouault To: Jeremy Palmer Cc: "gdal-dev@lists.osgeo.org" Sent: 30/11/2012 11:15 AM Subject: Re: [gdal-dev] 64bit integers Le jeudi 29 novembre 2012 23:10:08, Jeremy Palmer a écrit : > Thanks. > > Any idea if the 64bit proposal is going to happen any time soon? (Not before GDAL 1.10 release, so as to keep GDAL 1.X ABI) Perhaps are you volunteering ;-) ? > > If not, is there an option to implement functionality to cast 64bit fields > to string in 1.9.X? This function could still be useful once 64bit > integers are implemented. This could be done, but the work must be done on a driver-by-driver basis. > > Cheers > Jeremy > > > - Original Message - > From: Even Rouault > To: "gdal-dev@lists.osgeo.org" > Sent: 30/11/2012 10:45 AM > Subject: Re: [gdal-dev] 64bit integers > > Le jeudi 29 novembre 2012 22:36:54, Jürgen E. Fischer a écrit : > > Hi Even, > > > > On Thu, 29. Nov 2012 at 20:53:57 +0100, Even Rouault wrote: > > > With latest trunk, you can set the OGR_SETFIELD_NUMERIC_WARNING > > > configruation option to YES. This should generate a warning if the > > > conversion to int overflows. > > > > Um, that was meant to produce a warning when a non-numeric (or partly > > numeric) string is parsed incompletely to a number. Overflows are not > > yet covered (we don't reset and check errno for ERANGE after the > > conversion). > > Those checks are now done per http://trac.osgeo.org/gdal/changeset/25265 > > > Jürgen > > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > > This message contains information, which is confidential and may be subject > to legal privilege. If you are not the intended recipient, you must not > peruse, use, disseminate, distribute or copy this message. If you have > received this message in error, please notify us immediately (Phone 0800 > 665 463 or i...@linz.govt.nz) and destroy the original message. LINZ > accepts no responsibility for changes to this email, or for any > attachments, after its transmission from LINZ. Thank You. This message contains information, which is confidential and may be subject to legal privilege. If you are not the intended recipient, you must not peruse, use, disseminate, distribute or copy this message. If you have received this message in error, please notify us immediately (Phone 0800 665 463 or i...@linz.govt.nz) and destroy the original message. LINZ accepts no responsibility for changes to this email, or for any attachments, after its transmission from LINZ. Thank You. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] 64bit integers
Le jeudi 29 novembre 2012 23:10:08, Jeremy Palmer a écrit : > Thanks. > > Any idea if the 64bit proposal is going to happen any time soon? (Not before GDAL 1.10 release, so as to keep GDAL 1.X ABI) Perhaps are you volunteering ;-) ? > > If not, is there an option to implement functionality to cast 64bit fields > to string in 1.9.X? This function could still be useful once 64bit > integers are implemented. This could be done, but the work must be done on a driver-by-driver basis. > > Cheers > Jeremy > > > - Original Message - > From: Even Rouault > To: "gdal-dev@lists.osgeo.org" > Sent: 30/11/2012 10:45 AM > Subject: Re: [gdal-dev] 64bit integers > > Le jeudi 29 novembre 2012 22:36:54, Jürgen E. Fischer a écrit : > > Hi Even, > > > > On Thu, 29. Nov 2012 at 20:53:57 +0100, Even Rouault wrote: > > > With latest trunk, you can set the OGR_SETFIELD_NUMERIC_WARNING > > > configruation option to YES. This should generate a warning if the > > > conversion to int overflows. > > > > Um, that was meant to produce a warning when a non-numeric (or partly > > numeric) string is parsed incompletely to a number. Overflows are not > > yet covered (we don't reset and check errno for ERANGE after the > > conversion). > > Those checks are now done per http://trac.osgeo.org/gdal/changeset/25265 > > > Jürgen > > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > > This message contains information, which is confidential and may be subject > to legal privilege. If you are not the intended recipient, you must not > peruse, use, disseminate, distribute or copy this message. If you have > received this message in error, please notify us immediately (Phone 0800 > 665 463 or i...@linz.govt.nz) and destroy the original message. LINZ > accepts no responsibility for changes to this email, or for any > attachments, after its transmission from LINZ. Thank You. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] 64bit integers
Thanks. Any idea if the 64bit proposal is going to happen any time soon? If not, is there an option to implement functionality to cast 64bit fields to string in 1.9.X? This function could still be useful once 64bit integers are implemented. Cheers Jeremy - Original Message - From: Even Rouault To: "gdal-dev@lists.osgeo.org" Sent: 30/11/2012 10:45 AM Subject: Re: [gdal-dev] 64bit integers Le jeudi 29 novembre 2012 22:36:54, Jürgen E. Fischer a écrit : > Hi Even, > > On Thu, 29. Nov 2012 at 20:53:57 +0100, Even Rouault wrote: > > With latest trunk, you can set the OGR_SETFIELD_NUMERIC_WARNING > > configruation option to YES. This should generate a warning if the > > conversion to int overflows. > > Um, that was meant to produce a warning when a non-numeric (or partly > numeric) string is parsed incompletely to a number. Overflows are not > yet covered (we don't reset and check errno for ERANGE after the > conversion). Those checks are now done per http://trac.osgeo.org/gdal/changeset/25265 > > > Jürgen ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev This message contains information, which is confidential and may be subject to legal privilege. If you are not the intended recipient, you must not peruse, use, disseminate, distribute or copy this message. If you have received this message in error, please notify us immediately (Phone 0800 665 463 or i...@linz.govt.nz) and destroy the original message. LINZ accepts no responsibility for changes to this email, or for any attachments, after its transmission from LINZ. Thank You. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] 64bit integers
Le jeudi 29 novembre 2012 22:36:54, Jürgen E. Fischer a écrit : > Hi Even, > > On Thu, 29. Nov 2012 at 20:53:57 +0100, Even Rouault wrote: > > With latest trunk, you can set the OGR_SETFIELD_NUMERIC_WARNING > > configruation option to YES. This should generate a warning if the > > conversion to int overflows. > > Um, that was meant to produce a warning when a non-numeric (or partly > numeric) string is parsed incompletely to a number. Overflows are not > yet covered (we don't reset and check errno for ERANGE after the > conversion). Those checks are now done per http://trac.osgeo.org/gdal/changeset/25265 > > > Jürgen ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] 64bit integers
Hi Even, On Thu, 29. Nov 2012 at 20:53:57 +0100, Even Rouault wrote: > With latest trunk, you can set the OGR_SETFIELD_NUMERIC_WARNING configruation > option to YES. This should generate a warning if the conversion to int > overflows. Um, that was meant to produce a warning when a non-numeric (or partly numeric) string is parsed incompletely to a number. Overflows are not yet covered (we don't reset and check errno for ERANGE after the conversion). Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31 Dipl.-Inf. (FH) Rheinstraße 13Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de committ(ed|ing) to Quantum GIS IRC: jef on FreeNode -- norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH Rheinstrasse 13, 26506 Norden GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] 64bit integers
Le jeudi 29 novembre 2012 05:34:11, Jeremy Palmer a écrit : > Hi Brent, > > It's in PostgreSQL. We could convert the field to a string data type, but > that's not the point. OGR is currently corrupting data without telling the > user! With latest trunk, you can set the OGR_SETFIELD_NUMERIC_WARNING configruation option to YES. This should generate a warning if the conversion to int overflows. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Creating new column with filename, scripting shapefiles
Even- your guidance and correction was the solution that worked for me. Thank
you! _ joe
On Nov 29, 2012, at 11:00:47AM, Even Rouault
wrote:
> Le jeudi 29 novembre 2012 16:28:33, Joe Larson a écrit :
>> I have tried these three methods to add a filename column while scripting a
>> folder of shapefiles, with a Bash script - which results in `Warning 6:
>> Normalized/laundered field name` & `ERROR 1: SQL Expression Parsing Error:
>> syntax error` messages and NULL values in the created column :
>>
>> #1
>>
>> for f in *.shp;
>>
>> do
>>
>> name=${f%.shp}
>>
>> ogrinfo $f -sql "ALTER TABLE $name ADD COLUMN filename character(10)"
>> ogrinfo $f -sql "UPDATE TABLE $name filename = '$f'"
>
> --> UPDATE syntax is not supported by OGR SQL dialect. See
> http://gdal.org/ogr/ogr_sql.html
>
> If you use the development version of GDAL (GDAL 1.10dev), you could however
> use the SQLite dialect to do UPDATEs : http://gdal.org/ogr/ogr_sql_sqlite.html
>
> Actually your SQL is incorrect. The correct syntax would be :
>
> ogrinfo $f -dialect SQLite -sql "UPDATE $name SET filename = '$f'"
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Creating new column with filename, scripting shapefiles
On Thu, Nov 29, 2012 at 3:54 PM, Chaitanya kumar CH
wrote:
> Joe,
>
> What was the full warning message about the normalized/laundered field name?
> Field name is modified when the name is longer than 10 characters or when a
> field with same name exists.
> Check the name of the newly created field.
>
> As per the update command, I don't think the update command is implemented
> in the ogr sql yet. You can do it in the sqlite format, among other rdbms
> formats. Use ogr2ogr to convert it to sqlite. update it. convert it back to
> shapefile.
>
or use the ogr-sqlite interface that is present in gdal 1.10 - it
supposedly works with all ogr data sources
http://www.gdal.org/ogr/ogr_sql_sqlite.html
>
> On Thu, Nov 29, 2012 at 8:58 PM, Joe Larson wrote:
>>
>> I have tried these three methods to add a filename column while scripting
>> a folder of shapefiles, with a Bash script - which results in `Warning 6:
>> Normalized/laundered field name` & `ERROR 1: SQL Expression Parsing Error:
>> syntax error` messages and NULL values in the created column :
>>
>> #1
>>
>> for f in *.shp;
>>
>> do
>>
>> name=${f%.shp}
>>
>> ogrinfo $f -sql "ALTER TABLE $name ADD COLUMN filename character(10)"
>> ogrinfo $f -sql "UPDATE TABLE $name filename = '$f'"
>> done;
>>
>> #2
>>
>> for f in *.shp;
>>
>> do
>>
>> name=`echo "$f"|sed 's/\.shp$//g'`
>>
>> ogrinfo $f -sql "ALTER TABLE $name ADD COLUMN filename character(10)"
>> ogrinfo $f -sql "UPDATE TABLE $name filename = '$f'"
>> done;
>>
>> #3
>>
>> for f in *.shp;
>>
>> do
>>
>> name=`basename $f .shp`
>>
>> ogrinfo $f -sql "ALTER TABLE $name ADD COLUMN filename character(10)"
>> ogrinfo $f -sql "UPDATE TABLE $name filename = '$f'"
>> done;
>>
>>
>> There's an example here http://trac.osgeo.org/gdal/wiki/FAQVector called
>> "How do I include the source filename in a field when merging hundreds of
>> shapefiles (Windows)?" I also cannot get this to work - getting
>> "unrecognized fieldname" message.
>>
>> Perhaps my variable does not work in the Bash SQL statement. I'm not sure
>> what's going on in the Windows example.
>>
>> Regards,
>> Joe Larson
>>
>> ___
>> gdal-dev mailing list
>> gdal-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
>
>
> --
> Best regards,
> Chaitanya kumar CH.
>
> +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 mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Creating new column with filename, scripting shapefiles
Le jeudi 29 novembre 2012 16:28:33, Joe Larson a écrit :
> I have tried these three methods to add a filename column while scripting a
> folder of shapefiles, with a Bash script - which results in `Warning 6:
> Normalized/laundered field name` & `ERROR 1: SQL Expression Parsing Error:
> syntax error` messages and NULL values in the created column :
>
> #1
>
> for f in *.shp;
>
> do
>
> name=${f%.shp}
>
> ogrinfo $f -sql "ALTER TABLE $name ADD COLUMN filename character(10)"
> ogrinfo $f -sql "UPDATE TABLE $name filename = '$f'"
--> UPDATE syntax is not supported by OGR SQL dialect. See
http://gdal.org/ogr/ogr_sql.html
If you use the development version of GDAL (GDAL 1.10dev), you could however
use the SQLite dialect to do UPDATEs : http://gdal.org/ogr/ogr_sql_sqlite.html
Actually your SQL is incorrect. The correct syntax would be :
ogrinfo $f -dialect SQLite -sql "UPDATE $name SET filename = '$f'"
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Creating new column with filename, scripting shapefiles
Chaitanya - I believe the normalized/laundered message is a non-issue at this
point. I only get that message when I repeatedly run my Bash script against the
folder of shapefiles - so it's changing the 'filename' column to 'filename_1'
when creating a new column.
I really like your idea of sqlite and will give this a try. Thank you very much
_ joe
On Nov 29, 2012, at 9:54:49AM, Chaitanya kumar CH
wrote:
> Joe,
>
> What was the full warning message about the normalized/laundered field name?
> Field name is modified when the name is longer than 10 characters or when a
> field with same name exists.
> Check the name of the newly created field.
>
> As per the update command, I don't think the update command is implemented in
> the ogr sql yet. You can do it in the sqlite format, among other rdbms
> formats. Use ogr2ogr to convert it to sqlite. update it. convert it back to
> shapefile.
>
>
> On Thu, Nov 29, 2012 at 8:58 PM, Joe Larson wrote:
> I have tried these three methods to add a filename column while scripting a
> folder of shapefiles, with a Bash script - which results in `Warning 6:
> Normalized/laundered field name` & `ERROR 1: SQL Expression Parsing Error:
> syntax error` messages and NULL values in the created column :
>
> #1
>
> for f in *.shp;
>
> do
>
> name=${f%.shp}
>
> ogrinfo $f -sql "ALTER TABLE $name ADD COLUMN filename character(10)"
> ogrinfo $f -sql "UPDATE TABLE $name filename = '$f'"
> done;
>
> #2
>
> for f in *.shp;
>
> do
>
> name=`echo "$f"|sed 's/\.shp$//g'`
>
> ogrinfo $f -sql "ALTER TABLE $name ADD COLUMN filename character(10)"
> ogrinfo $f -sql "UPDATE TABLE $name filename = '$f'"
> done;
>
> #3
>
> for f in *.shp;
>
> do
>
> name=`basename $f .shp`
>
> ogrinfo $f -sql "ALTER TABLE $name ADD COLUMN filename character(10)"
> ogrinfo $f -sql "UPDATE TABLE $name filename = '$f'"
> done;
>
>
> There's an example here http://trac.osgeo.org/gdal/wiki/FAQVector called "How
> do I include the source filename in a field when merging hundreds of
> shapefiles (Windows)?" I also cannot get this to work - getting "unrecognized
> fieldname" message.
>
> Perhaps my variable does not work in the Bash SQL statement. I'm not sure
> what's going on in the Windows example.
>
> Regards,
> Joe Larson
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
>
> --
> Best regards,
> Chaitanya kumar CH.
>
> +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] Creating new column with filename, scripting shapefiles
Joe,
What was the full warning message about the normalized/laundered field
name? Field name is modified when the name is longer than 10 characters or
when a field with same name exists.
Check the name of the newly created field.
As per the update command, I don't think the update command is implemented
in the ogr sql yet. You can do it in the sqlite format, among other rdbms
formats. Use ogr2ogr to convert it to sqlite. update it. convert it back to
shapefile.
On Thu, Nov 29, 2012 at 8:58 PM, Joe Larson wrote:
> I have tried these three methods to add a filename column while scripting
> a folder of shapefiles, with a Bash script - which results in `Warning 6:
> Normalized/laundered field name` & `ERROR 1: SQL Expression Parsing Error:
> syntax error` messages and NULL values in the created column :
>
> #1
>
> for f in *.shp;
>
> do
>
> name=${f%.shp}
>
> ogrinfo $f -sql "ALTER TABLE $name ADD COLUMN filename character(10)"
> ogrinfo $f -sql "UPDATE TABLE $name filename = '$f'"
> done;
>
> #2
>
> for f in *.shp;
>
> do
>
> name=`echo "$f"|sed 's/\.shp$//g'`
>
> ogrinfo $f -sql "ALTER TABLE $name ADD COLUMN filename character(10)"
> ogrinfo $f -sql "UPDATE TABLE $name filename = '$f'"
> done;
>
> #3
>
> for f in *.shp;
>
> do
>
> name=`basename $f .shp`
>
> ogrinfo $f -sql "ALTER TABLE $name ADD COLUMN filename character(10)"
> ogrinfo $f -sql "UPDATE TABLE $name filename = '$f'"
> done;
>
>
> There's an example here http://trac.osgeo.org/gdal/wiki/FAQVector called
> "How do I include the source filename in a field when merging hundreds of
> shapefiles (Windows)?" I also cannot get this to work - getting
> "unrecognized fieldname" message.
>
> Perhaps my variable does not work in the Bash SQL statement. I'm not sure
> what's going on in the Windows example.
>
> Regards,
> Joe Larson
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
--
Best regards,
Chaitanya kumar CH.
+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] Creating new column with filename, scripting shapefiles
I have tried these three methods to add a filename column while scripting a
folder of shapefiles, with a Bash script - which results in `Warning 6:
Normalized/laundered field name` & `ERROR 1: SQL Expression Parsing Error:
syntax error` messages and NULL values in the created column :
#1
for f in *.shp;
do
name=${f%.shp}
ogrinfo $f -sql "ALTER TABLE $name ADD COLUMN filename character(10)"
ogrinfo $f -sql "UPDATE TABLE $name filename = '$f'"
done;
#2
for f in *.shp;
do
name=`echo "$f"|sed 's/\.shp$//g'`
ogrinfo $f -sql "ALTER TABLE $name ADD COLUMN filename character(10)"
ogrinfo $f -sql "UPDATE TABLE $name filename = '$f'"
done;
#3
for f in *.shp;
do
name=`basename $f .shp`
ogrinfo $f -sql "ALTER TABLE $name ADD COLUMN filename character(10)"
ogrinfo $f -sql "UPDATE TABLE $name filename = '$f'"
done;
There's an example here http://trac.osgeo.org/gdal/wiki/FAQVector called "How
do I include the source filename in a field when merging hundreds of shapefiles
(Windows)?" I also cannot get this to work - getting "unrecognized fieldname"
message.
Perhaps my variable does not work in the Bash SQL statement. I'm not sure
what's going on in the Windows example.
Regards,
Joe Larson___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdalwarp produces all black output
On Thu, Nov 29, 2012 at 2:02 AM, mortac8 wrote: > Newbie question here. I am trying to convert a DTED1 image to GeoTiff. The > below command gives me a mosaic.tif image that is totally black. > > gdalwarp -ot Int16 n29.dt1 mosaic.tif > > Here is a link to my source image: > https://www.dropbox.com/s/zjnbshnwmu67o3o/n29.dt1 > > Any advice is greatly appreciated! I am on Windows using FWTools 2.4.7. BTW, the gdal binaries that ships with fwtools is quite old - you should consider installing a more recent version of gdal (either Tomas' builds[2] or from osgeo4w[3]) from the gdal download page [1] you can read: Important note: the FWTools binaries are not currently updated with the latest GDAL versions. In order to benefit from the latest and greatest, you can refer to the other binary builds mentionned above. [1] http://trac.osgeo.org/gdal/wiki/DownloadingGdalBinaries#Windows [2] http://www.gisinternals.com/sdk/ [3] http://trac.osgeo.org/osgeo4w > > Thanks! > Ashley > > > > -- > View this message in context: > http://osgeo-org.1560.n6.nabble.com/gdalwarp-produces-all-black-output-tp5019465.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] Cannot read UTM Ozi .map file
Le 28/11/2012 22:54, Nik Sands a écrit : After applying the suggested patch, it no longer errors out in the same way, however, I now get another error just a little further on in my code. - Failed to get geo-transform (error 3) for file: Cradle Mountain_ozf.map - I'm afraid this is a bit beyond me, so if you can help, I'd be very grateful. Did you notice that gdalinfo reports the same error ? $ gdalinfo --debug on -noct Cradle\ Mountain_ozf.map GDAL: GDALLoadOziMapFile(Cradle Mountain_ozf.map) found file, wasn't able to derive a first order geotransform. Using points as GCPs. GDAL: GDALOpen(Cradle Mountain_ozf.map, this=0x155a4a0) succeeds as OZI. Driver: OZI/OziExplorer Image File GDAL: GDALDefaultOverviews::OverviewScan() Files: Cradle Mountain_ozf.map Size is 6535, 11880 Coordinate System is `' GCP Projection = PROJCS["UTM Zone 55, Southern Hemisphere", GEOGCS["GDA94", DATUM["Geocentric_Datum_of_Australia_1994", SPHEROID["GRS 1980",6378137,298.257222101, AUTHORITY["EPSG","7019"]], TOWGS84[0,0,0,0,0,0,0], AUTHORITY["EPSG","6283"]], PRIMEM["Greenwich",0, AUTHORITY["EPSG","8901"]], UNIT["degree",0.0174532925199433, AUTHORITY["EPSG","9122"]], AUTHORITY["EPSG","4283"]], PROJECTION["Transverse_Mercator"], PARAMETER["latitude_of_origin",0], PARAMETER["central_meridian",147], PARAMETER["scale_factor",0.9996], PARAMETER["false_easting",50], PARAMETER["false_northing",1000], UNIT["Meter",1]] GCP[ 0]: Id=, Info= (749,50) -> (41,5397000,0) GCP[ 1]: Id=, Info= (4697,38) -> (415000,5397000,0) GCP[ 2]: Id=, Info= (4668,11128) -> (415000,5383000,0) GCP[ 3]: Id=, Info= (757,11164) -> (41,5383000,0) GCP[ 4]: Id=, Info= (1532,5600) -> (411000,539,0) GCP[ 5]: Id=, Info= (3112,1611) -> (413000,5395000,0) GCP[ 6]: Id=, Info= (3894,7962) -> (414000,5387000,0) GCP[ 7]: Id=, Info= (3890,4794) -> (414000,5391000,0) GCP[ 8]: Id=, Info= (2318,9563) -> (412000,5385000,0) Corner Coordinates: Upper Left (0.0,0.0) Lower Left (0.0,11880.0) Upper Right ( 6535.0,0.0) Lower Right ( 6535.0,11880.0) Center ( 3267.5, 5940.0) Band 1 Block=64x64 Type=Byte, ColorInterp=Palette Overviews: 1634x2970, 654x1188, 327x594, 163x297, 65x119 Color Table (RGB with 256 entries) GDAL: GDALClose(Cradle Mountain_ozf.map, this=0x155a4a0) This is because the quality of the scan is very bad. Look at the text "No Camping Allowed", that appears almost twice. You can ask GDAL to ignore the problem by setting the environment variable OZI_APPROX_GEOTRANSFORM to the value YES (In this case, you can drop the patch I sent you yesterday) : $ OZI_APPROX_GEOTRANSFORM=YES gdalinfo -noct Cradle\ Mountain_ozf.map Driver: OZI/OziExplorer Image File Files: Cradle Mountain_ozf.map Size is 6535, 11880 Coordinate System is: PROJCS["UTM Zone 55, Southern Hemisphere", GEOGCS["GDA94", DATUM["Geocentric_Datum_of_Australia_1994", SPHEROID["GRS 1980",6378137,298.257222101, AUTHORITY["EPSG","7019"]], TOWGS84[0,0,0,0,0,0,0], AUTHORITY["EPSG","6283"]], PRIMEM["Greenwich",0, AUTHORITY["EPSG","8901"]], UNIT["degree",0.0174532925199433, AUTHORITY["EPSG","9122"]], AUTHORITY["EPSG","4283"]], PROJECTION["Transverse_Mercator"], PARAMETER["latitude_of_origin",0], PARAMETER["central_meridian",147], PARAMETER["scale_factor",0.9996], PARAMETER["false_easting",50], PARAMETER["false_northing",1000], UNIT["Meter",1]] GeoTransform = 409038.6971553778, 1.27227951543291, 0.00115086216077703 5397071.561063163, -0.008135856054426157, -1.260559301556319 Corner Coordinates: Upper Left ( 409038.697, 5397071.561) (145d54'32.19"E, 41d34'22.31"S) Lower Left ( 409052.369, 5382096.117) (145d54'24.58"E, 41d42'27.83"S) Upper Right ( 417353.044, 5397018.393) (146d 0'31.13"E, 41d34'27.29"S) Lower Right ( 417366.716, 5382042.949) (146d 0'24.27"E, 41d42'32.82"S) Center ( 413202.707, 5389557.255) (145d57'28.05"E, 41d38'27.60"S) Band 1 Block=64x64 Type=Byte, ColorInterp=Palette Overviews: 1634x2970, 654x1188, 327x594, 163x297, 65x119 Color Table (RGB with 256 entries) ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
