[gdal-dev] PG: does OGR2OGR set the SRID correctly ?
Hi All, I've just uploaded a shape with ogr2ogr -f PostgreSQL PG:dbname='gis' host='10.0.1.40' port='5432' user='gis' password='gis' sebas.shp -lco 27700 -lco PRECISION=NO -progress -lco OVERWRITE=yes -lco dim=2 -nln sebas -overwrite but from select ST_SRID(wkb_geometry) from sebas; I'm getting 3 (with select ST_SRID(ST_SetSRID(wkb_geometry,27700)) from sebas; I'm getting the right value ) any ideas ? -- Sebastian E. Ovide ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] PG: does OGR2OGR set the SRID correctly ?
On Tue, Nov 30, 2010 at 11:30 AM, Sebastian E. Ovide sebastian.ov...@gmail.com wrote: Hi All, I've just uploaded a shape with ogr2ogr -f PostgreSQL PG:dbname='gis' host='10.0.1.40' port='5432' user='gis' password='gis' sebas.shp -lco 27700 -lco PRECISION=NO -progress -lco OVERWRITE=yes -lco dim=2 -nln sebas -overwrite but from select ST_SRID(wkb_geometry) from sebas; I'm getting 3 (with select ST_SRID(ST_SetSRID(wkb_geometry,27700)) from sebas; I'm getting the right value ) any ideas ? -- Sebastian E. Ovide ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev Hi Sebastian, Did you test this? ogr2ogr -f PostgreSQL -a_srs the data srid PG:dbname='gis' host='10.0.1.40' port='5432' user='gis' password='gis' sebas.shp -lco 27700 -lco PRECISION=NO -progress -lco OVERWRITE=yes -lco dim=2 -nln sebas -overwrite -- Jorge Arévalo Internet Mobilty Division, DEIMOS jorge.arev...@deimos-space.com http://mobility.grupodeimos.com/ http://gis4free.wordpress.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] PG: does OGR2OGR set the SRID correctly ?
Selon Sebastian E. Ovide sebastian.ov...@gmail.com: Sebastian, The option -lco 27700 has no effect. The correct syntax would be something like -lco SRID=27700, but there's no such option, so don't loose your time trying that ;-) The SRID is set automatically by comparing the SRS of the source layer with what exists in the spatial_ref_sys table (or the one you can set with the -a_srs EPSG:27700 as suggested by Jorge). If there's a match, then the SRID from spatial_ref_sys will be used. Otherwise the PG driver will add a new entry in the spatial_ref_sys table (and the SRID number will not be equal to the EPSG code). Make sure you've filled the spatial_ref_sys table with the appropriate PostGIS .sql script. The '3' you get sounds like the spatial_ref_sys table of this database was empty and that the PG driver added new entries in it. Best regards, Hi All, I've just uploaded a shape with ogr2ogr -f PostgreSQL PG:dbname='gis' host='10.0.1.40' port='5432' user='gis' password='gis' sebas.shp -lco 27700 -lco PRECISION=NO -progress -lco OVERWRITE=yes -lco dim=2 -nln sebas -overwrite but from select ST_SRID(wkb_geometry) from sebas; I'm getting 3 (with select ST_SRID(ST_SetSRID(wkb_geometry,27700)) from sebas; I'm getting the right value ) any ideas ? -- Sebastian E. Ovide ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] No Simplify function
Hi, I have installed GDAL 1.7.1 with GEOS 3.0.0 on my Solaris machine. But I cannot see any function as Simplify() as given in the tutorial: virtual OGRGeometry * Simplify (double dTolerance) const -- Simplify the geometry. Please can you guide me if I am missing anything here or do I need latest GDAL (1.7.3) installed Eagerly waiting for your reply. Thanks, Namrata -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/No-Simplify-function-tp5788134p5788134.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] No Simplify function
Namrata wrote: Hi, I have installed GDAL 1.7.1 with GEOS 3.0.0 on my Solaris machine. But I cannot see any function as Simplify() as given in the tutorial: virtual OGRGeometry * Simplify (double dTolerance) const -- Simplify the geometry. Please can you guide me if I am missing anything here or do I need latest GDAL (1.7.3) installed Eagerly waiting for your reply. Namrata, A brief review suggests to me that the Simplify method was added since the 1.7 release, and that it has not been backported to the 1.7.x stable release series. The only way to get it is to download a development snapshot and build from that. Daily development snapshots are available at: http://www.gdal.org/daily 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] PG: does OGR2OGR set the SRID correctly ?
I've replaced the -lco 27700 with -a_srs EPSG:27700 now select ST_SRID(wkb_geometry) from sebas gives 4... any ideas ? On Tue, Nov 30, 2010 at 10:59 AM, Even Rouault even.roua...@mines-paris.org wrote: Selon Sebastian E. Ovide sebastian.ov...@gmail.com: Sebastian, The option -lco 27700 has no effect. The correct syntax would be something like -lco SRID=27700, but there's no such option, so don't loose your time trying that ;-) The SRID is set automatically by comparing the SRS of the source layer with what exists in the spatial_ref_sys table (or the one you can set with the -a_srs EPSG:27700 as suggested by Jorge). If there's a match, then the SRID from spatial_ref_sys will be used. Otherwise the PG driver will add a new entry in the spatial_ref_sys table (and the SRID number will not be equal to the EPSG code). Make sure you've filled the spatial_ref_sys table with the appropriate PostGIS .sql script. The '3' you get sounds like the spatial_ref_sys table of this database was empty and that the PG driver added new entries in it. Best regards, Hi All, I've just uploaded a shape with ogr2ogr -f PostgreSQL PG:dbname='gis' host='10.0.1.40' port='5432' user='gis' password='gis' sebas.shp -lco 27700 -lco PRECISION=NO -progress -lco OVERWRITE=yes -lco dim=2 -nln sebas -overwrite but from select ST_SRID(wkb_geometry) from sebas; I'm getting 3 (with select ST_SRID(ST_SetSRID(wkb_geometry,27700)) from sebas; I'm getting the right value ) any ideas ? -- Sebastian E. Ovide -- Sebastian E. Ovide ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] PG: does OGR2OGR set the SRID correctly ?
Sebastian, I'd suggest checking what I wrote at the end of my previous email : Make sure you've filled the spatial_ref_sys table with the appropriate PostGIS .sql script. The '3' you get sounds like the spatial_ref_sys table of this database was empty and that the PG driver added new entries in it. The mentionned .sql script is spatial_ref_sys.sql. See http://postgis.refractions.net/documentation/manual-1.5/ch02.html#id2630392 I've replaced the -lco 27700 with -a_srs EPSG:27700 now select ST_SRID(wkb_geometry) from sebas gives 4... any ideas ? On Tue, Nov 30, 2010 at 10:59 AM, Even Rouault even.roua...@mines-paris.org wrote: Selon Sebastian E. Ovide sebastian.ov...@gmail.com: Sebastian, The option -lco 27700 has no effect. The correct syntax would be something like -lco SRID=27700, but there's no such option, so don't loose your time trying that ;-) The SRID is set automatically by comparing the SRS of the source layer with what exists in the spatial_ref_sys table (or the one you can set with the -a_srs EPSG:27700 as suggested by Jorge). If there's a match, then the SRID from spatial_ref_sys will be used. Otherwise the PG driver will add a new entry in the spatial_ref_sys table (and the SRID number will not be equal to the EPSG code). Make sure you've filled the spatial_ref_sys table with the appropriate PostGIS .sql script. The '3' you get sounds like the spatial_ref_sys table of this database was empty and that the PG driver added new entries in it. Best regards, Hi All, I've just uploaded a shape with ogr2ogr -f PostgreSQL PG:dbname='gis' host='10.0.1.40' port='5432' user='gis' password='gis' sebas.shp -lco 27700 -lco PRECISION=NO -progress -lco OVERWRITE=yes -lco dim=2 -nln sebas -overwrite but from select ST_SRID(wkb_geometry) from sebas; I'm getting 3 (with select ST_SRID(ST_SetSRID(wkb_geometry,27700)) from sebas; I'm getting the right value ) any ideas ? -- Sebastian E. Ovide -- Sebastian E. Ovide ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] PG: does OGR2OGR set the SRID correctly ?
Hi Even, I've missed that part... just to confirm that with *psql -d [yourdatabase] -f spatial_ref_sys.sql and deleting those extra lines created automatically, now I can upload shapes with the right SRID* **thanks ! On Tue, Nov 30, 2010 at 2:32 PM, Even Rouault even.roua...@mines-paris.orgwrote: Sebastian, I'd suggest checking what I wrote at the end of my previous email : Make sure you've filled the spatial_ref_sys table with the appropriate PostGIS .sql script. The '3' you get sounds like the spatial_ref_sys table of this database was empty and that the PG driver added new entries in it. The mentionned .sql script is spatial_ref_sys.sql. See http://postgis.refractions.net/documentation/manual-1.5/ch02.html#id2630392 I've replaced the -lco 27700 with -a_srs EPSG:27700 now select ST_SRID(wkb_geometry) from sebas gives 4... any ideas ? On Tue, Nov 30, 2010 at 10:59 AM, Even Rouault even.roua...@mines-paris.org wrote: Selon Sebastian E. Ovide sebastian.ov...@gmail.com: Sebastian, The option -lco 27700 has no effect. The correct syntax would be something like -lco SRID=27700, but there's no such option, so don't loose your time trying that ;-) The SRID is set automatically by comparing the SRS of the source layer with what exists in the spatial_ref_sys table (or the one you can set with the -a_srs EPSG:27700 as suggested by Jorge). If there's a match, then the SRID from spatial_ref_sys will be used. Otherwise the PG driver will add a new entry in the spatial_ref_sys table (and the SRID number will not be equal to the EPSG code). Make sure you've filled the spatial_ref_sys table with the appropriate PostGIS .sql script. The '3' you get sounds like the spatial_ref_sys table of this database was empty and that the PG driver added new entries in it. Best regards, Hi All, I've just uploaded a shape with ogr2ogr -f PostgreSQL PG:dbname='gis' host='10.0.1.40' port='5432' user='gis' password='gis' sebas.shp -lco 27700 -lco PRECISION=NO -progress -lco OVERWRITE=yes -lco dim=2 -nln sebas -overwrite but from select ST_SRID(wkb_geometry) from sebas; I'm getting 3 (with select ST_SRID(ST_SetSRID(wkb_geometry,27700)) from sebas; I'm getting the right value ) any ideas ? -- Sebastian E. Ovide -- Sebastian E. Ovide -- Sebastian E. Ovide ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] ECMWF's GRIBs and NetCDFs
Hi I'm using ECMWF's GRIB files and, I realized that there is a small error in geolocation (that can be fixed with gdal_translate). But, since I changed to winGRASS (that uses gdal1.5) I'm not able to use ECMWF's GRIB. Since ECMWF's data is also provided in NetCDF, I would like to know if there is any known issue on using NetCDF data in GDAL1.5? (I didn't find anything). Thanks Antonio R. __ Information from ESET NOD32 Antivirus, version of virus signature database 5661 (20101130) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ECMWF's GRIBs and NetCDFs
On 30-11-2010 15:03, António Rocha wrote: Hi I'm using ECMWF's GRIB files and, I realized that there is a small error in geolocation (that can be fixed with gdal_translate). But, since I changed to winGRASS (that uses gdal1.5) I'm not able to use ECMWF's GRIB. Since ECMWF's data is also provided in NetCDF, I would like to know if there is any known issue on using NetCDF data in GDAL1.5? (I didn't find anything). António, A few http://trac.osgeo.org/gdal/ticket/1672 http://trac.osgeo.org/gdal/ticket/3797 but probably the most important one (the flip up-down issue) http://trac.osgeo.org/gdal/ticket/3575 Joaquim Thanks Antonio R. __ Information from ESET NOD32 Antivirus, version of virus signature database 5661 (20101130) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.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
[gdal-dev] Creating a range from given points
Dear list, Please see in attached image what I am aiming to achieve with GDAL. The tool creating it is here, but I don't have arcgis: http://resources.arcgis.com/fr/gallery/file/geoprocessing/details?entryID=1FECB539-1422-2418-7FE1-77F9D088402D The input is a set of points and a fixed grid (10x10km). The output a subset of the grid based on the points with the cells interlinked by some logic. My idea (probably not optimal): - convert the points to gridcell centroids - draw a line between the point and its neighbours - if the distance is inferior to a certain value - intersect the line with the grid and keep the intersected cells - result: assemble resulting cells and export Not being a spatial expert, I'm not sure though this is the good way. Could you have a look and perhaps give me a few hints? Thanks a lot! Kevin ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Re: Updating GDAL on OSGEO4w (windows)
Hello Jurgen But you're running gdalinfo from the same shell, that you ran gdal16/gdal17/gdaldev and your current directory is _not_ %OSGEO4W_ROOT%\bin? Uhm Maybe I wasn't clear. I run gdal16 in C:/osgeo4w/bin and then I did gdalinfo --version I attached a screenshot that exemplifies it Thanks Luisa attachment: gdal16_01.PNG___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: Updating GDAL on OSGEO4w (windows)
Luisa Peña wrote: Hello Jurgen But you're running gdalinfo from the same shell, that you ran gdal16/gdal17/gdaldev and your current directory is _not_ %OSGEO4W_ROOT%\bin? Uhm Maybe I wasn't clear. I run gdal16 in C:/osgeo4w/bin and then I did gdalinfo --version I attached a screenshot that exemplifies it Luisa, The problem is that you were in C:\OSGeo4W\bin at the time you ran gdalinfo. Executables in the local directory take precidence over what is at the front of the path. If you did it from another location you should see you are running the 1.6.x version. Thanks for the screen shot - it helps at lot to see exactly what you were doing in context to diagnose an issue like this. 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] Re: Updating GDAL on OSGEO4w (windows)
Luisa Peña wrote: You are absolutely rightr. It worked :) But, if I close the shell and open again, GDAL15 is again the pre-defined GDAL. How can I have this as defined? Are you familiar with winGRASS on OSGEO4w? My idea is to change current gdal (15) to gdal16 Or 18. Are you aware of anything regarding that? Luisa, The gdal16 command is just a bat file changing a few environment variables for the local shell - primary the path. It does not have any effect beyond the current shell. Also, it is affecting which GDAL utilities you pick up at the command line. It does not affect which version of GDAL is used at runtime by things like GRASS, MapServer or QGIS. These are all linked against a particular version of GDAL - in the case of GRASS 1.5. So if you want to work with GRIB files I would suggest running gdal16 in a shell, and then using gdal_translate to convert the grib file into a working format like GeoTIFF which you can subsequently use in GRASS. My hope is that after the GDAL 1.8 release we will make GDAL 1.8 the default version of GDAL in OSGeo4W and update GRASS and other packages to use it. The fact that 1.5 is still the default version in OSGeo4W is my fault. 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] No Simplify function
Frank Warmerdam warmer...@pobox.com writes: Namrata wrote: Hi, I have installed GDAL 1.7.1 with GEOS 3.0.0 on my Solaris machine. But I cannot see any function as Simplify() as given in the tutorial: virtual OGRGeometry * Simplify (double dTolerance) const -- Simplify the geometry. Please can you guide me if I am missing anything here or do I need latest GDAL (1.7.3) installed Eagerly waiting for your reply. Namrata, A brief review suggests to me that the Simplify method was added since the 1.7 release, and that it has not been backported to the 1.7.x stable release series. The only way to get it is to download a development snapshot and build from that. Daily development snapshots are available at: http://www.gdal.org/daily Best regards, I found that this site http://www.gdal.org/ogr/classOGRGeometry.html#fd3ea0ffa1e2994427032d0212206ccf states that simplify is available from version 1.8.0. \J ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] unresolved CPLAtomicAdd
I have been using GDAL 1.7.1 for a while now in debug mode without problems. I recently compiled GDAL in release mode and did not see any errors during the build process. When I build my application I get the following link error : unresolved external symbol _CPLAtomicAdd. I can see cpl_atomic_ops.obj after the build process so I know the method is getting compiled. I don't have this error in debug mode. Has anyone seen this problem and have a fix? Bruce This message and any enclosures are intended only for the addressee. Please notify the sender by email if you are not the intended recipient. If you are not the intended recipient, you may not use, copy, disclose, or distribute this message or its contents or enclosures to any other person and any such actions may be unlawful. Ball reserves the right to monitor and review all messages and enclosures sent to or from this email address.___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Re: how can I compile GDAL 1.7.3 with ecw 4.1 in Virsual Studio 2010
is nobody who can answer this issues under, or maybe I have to move this issue to the MapServer user otherwise I thank all who participate in this forum. -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/how-can-I-compile-GDAL-1-7-3-with-ecw-4-1-in-Virsual-Studio-2010-tp5765934p5790477.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: how can I compile GDAL 1.7.3 with ecw 4.1 in Virsual Studio 2010
GeoJoda wrote: is nobody who can answer this issues under, or maybe I have to move this issue to the MapServer user otherwise I thank all who participate in this forum. GeoJoda, I don't see any reason you are likely to have better luck on the MapServer list. Reviewing this thread I am left with the impression you have received lots of assistance, but you are just annoyed that no one has a step by step process for you to do it with the particular version of the SDK, and compiler you choose. If you want something very particular, you might consider paying someone for support. I've managed to build the ECW 4.1 SDK against GDAL with VS2008 without any unusual problems, but it is isn't something I'd wish on someone not experienced in development on windows - in particular building a mix of stuff. And frankly, holding the hand of someone who doesn't really know what they are doing isn't much fun. 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] GDAL contouring problem
Thanks for explaining the reason why the numeric value of 0.00 doesn't work as
a fixed level in gdal_contour while the value of 0 does.
I understand now the reason for this.
However I would have thought one could replace the test for 'zeroness' in
(atof(argv[i+1]) != 0 || EQUAL(argv[i+1], 0))
with a test for whether argv]i+1] is not empty and can be converted to a
numeric value.
This would be a duck-typing approach and more robust in my humble opinion.
Best regards
Ole Nielsen
-Original Message-
From: gdal-dev-boun...@lists.osgeo.org
[mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of
gdal-dev-requ...@lists.osgeo.org
Sent: Monday, 29 November 2010 8:41 PM
To: gdal-dev@lists.osgeo.org
Subject: gdal-dev Digest, Vol 78, Issue 64
Send gdal-dev mailing list submissions to
gdal-dev@lists.osgeo.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.osgeo.org/mailman/listinfo/gdal-dev
or, via email, send a message with subject or body 'help' to
gdal-dev-requ...@lists.osgeo.org
You can reach the person managing the list at
gdal-dev-ow...@lists.osgeo.org
When replying, please edit your Subject line so it is more specific
than Re: Contents of gdal-dev digest...
Today's Topics:
1. Re: GDAL contouring problem (Frank Warmerdam)
2. Re: GDAL contouring problem (Francis Markham)
3. Re: Delete a sqlite database (Ludovic Granjon)
4. Re: Error building GDAL with GEOS on Solaris (Namrata)
5. Making non-rectangular image edges transparent
(Just van den Broecke)
6. geotiff conflict (Julien Malik)
7. Re: RFC 31 - OGR 64bit Support (David Burken)
--
Message: 1
Date: Sun, 28 Nov 2010 23:24:56 -0500
From: Frank Warmerdam warmer...@pobox.com
Subject: Re: [gdal-dev] GDAL contouring problem
To: Ole Nielsen ole.niel...@aifdr.org
Cc: gdal-dev@lists.osgeo.org gdal-dev@lists.osgeo.org,
adeleb...@me.com adeleb...@me.com
Message-ID: 4cf32b18.2030...@pobox.com
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Ole Nielsen wrote:
I am posting this again without test files attached due the 50K size
limit. Anyone who wants to see them, please contact me directly.
--
We have observed interesting anomaly with gdal_contour when one of the
fixed levels is zero.
If the zero contour is expressed as 0.0 (or indeed 0.) gdal_contour
replies with the standard Usage message (see below). If the zero contour
is expressed as the integer 0 (or 0.0001) it works and produces the
expected contours.
Ole,
The gdal_contour program has some rather hokey heuristics to try and
recognise the end of the list of contour levels. The code looks like:
else if( EQUAL(argv[i],-fl) i argc-1 )
{
while( i argc-1
nFixedLevelCount
(int)(sizeof(adfFixedLevels)/sizeof(double))
(atof(argv[i+1]) != 0 || EQUAL(argv[i+1],0))
!EQUAL(argv[i+1], -3d))
adfFixedLevels[nFixedLevelCount++] = atof(argv[++i]);
}
So basically, it assumes everything is a level until something that
has a numeric value of 0 is encounter that isn't the specific string
0. So your analysis of the problem is essentially correct, but it is
more or less intentional as we try to support a list of levels with no
explicit end of list marker in the arguments to the command.
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
--
Message: 2
Date: Mon, 29 Nov 2010 16:48:56 +1100
From: Francis Markham fmark...@gmail.com
Subject: Re: [gdal-dev] GDAL contouring problem
To: Frank Warmerdam warmer...@pobox.com
Cc: gdal-dev@lists.osgeo.org gdal-dev@lists.osgeo.org, Ole Nielsen
ole.niel...@aifdr.org, adeleb...@me.com adeleb...@me.com
Message-ID:
aanlkti=xcxqx=nx1hbnjqmb6wvr3vfl6aoqpqhekx...@mail.gmail.com
Content-Type: text/plain; charset=ISO-8859-1
Is there any reason not to include a heuristic that uses strtod() or
similar to test for the zeroness of the last argument?
-Francis Markham
On 29 November 2010 15:24, Frank Warmerdam warmer...@pobox.com wrote:
Ole Nielsen wrote:
I am posting this again without test files attached due the 50K size
limit. Anyone who wants to see them, please contact me directly.
--
We have observed interesting anomaly with gdal_contour when one of the
fixed levels is zero.
If the zero contour is expressed as 0.0 (or indeed 0.) gdal_contour
replies with the standard Usage message (see below). If the zero contour is
expressed as the integer 0 (or 0.0001) it works and produces the
expected contours.
Ole,
