Re: [gdal-dev] why do I get a floating point nodata value from a byte raster?
Selon Richard Sharp richsh...@stanford.edu: On Fri, Aug 29, 2014 at 10:34 AM, Even Rouault even.roua...@spatialys.com wrote: Le jeudi 28 août 2014 23:32:38, Richard Sharp a écrit : I have a byte GTiff dataset that has a nodata value of 0 according to QGIS. Well, I've just created such a file, and with QGIS 1.8, the GUI display well the -3.4028230607370965e+38 value, but with 2.4, it displays 0. So seems to be on QGIS side. That said, -3.4028230607370965e+38 doesn't make sense as a nodata value for Byte, which can only range from 0 to 255. After some testing, it seems that QGIS displays 0 when the nodata value is out of the range of the data type. Thanks Evan. Just so I'm clear, you're saying that the raster had its nodata value set to something that exceeded its datatype range. Yes. In that case, it doesn't make sense to interpret the -3.4028230607370965e+38 as 0 in the byte range, Yes, QGIS should ignore the nodata value, as if there was nodata reported but rather as a nodata value defined for the valid pixels in the raster? I've not verified if it actually takes 0 as a nodata value, but if it does, yes that's unexpected. -- Spatialys - Geospatial professional services http://www.spatialys.com -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Convert S57 to image with S52 rendering
Sylvain, I couldn't build changing this line of code. But i have succeed using another version of Linux. I have built s52 on Ubuntu 14.04 and on our target platform Astra Linux (based on debian) On Ubuntu i running test/s52glx it displays some data from my file. But in Astra it says /S57data.c:337 in S57_geo2prj3dv(): ERROR: nothing to project to .. load a chart frist! ** ERROR:S57data.c:339:S57_geo2prj3dv: assertion failed: (0) S52.c:1332 in _trapSIG(): Signal SIGABRT(6) cought .. Abort/ -- View this message in context: http://osgeo-org.1560.x6.nabble.com/gdal-dev-Convert-S57-to-image-with-S52-rendering-tp4987897p5159559.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] ERROR: Points of LinearRing do not form a closed linestring
Hi everybody,
I created a script to filter some lidar data, and It worked perfectly
some weeks ago.
Now I have to run with different data but I obtain the following error
when I try to overlaps two geometry.
ERROR 1: IllegalArgumentException: Points of LinearRing do not form a
closed linestring
The code that I'm using is something similar to this
import osgeo.ogr as ogr
import osgeo.osr as osr
# this is the input vector file to read the features for filter the lidar point
inDatasource = ogr.Open('/incoming/james_lidar.json')
inLayer = inDatasource.GetLayer()
inFeature = inLayer.GetFeature(0)
geom = inFeature.geometry()
geom.ExportToWkt()
'POLYGON ((661300 5115700,661300 5117600,662300 5117600,662300 5115700))'
# this is the polygon of a lidar tile bounding box
wkt = 'POLYGON((66 5116000,66 5118000,661793 5118000,661793
5116000,66 5116000))'
poly = ogr.CreateGeometryFromWkt(wkt)
geoms.Overlaps(poly)
ERROR 1: IllegalArgumentException: Points of LinearRing do not form a
closed linestring
What I'm doing wrong?
--
ciao
Luca
http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Convert S57 to image with S52 rendering
Storkur, For further question on S52 I think it would be best if we e-mail directly instead of gdal-dev. All answer directly to you in my next mail. rgds, Sylvain. On Tue, 9/2/14, Storkur sovof...@yandex.ru wrote: Subject: Re: [gdal-dev] Convert S57 to image with S52 rendering To: gdal-dev@lists.osgeo.org Received: Tuesday, September 2, 2014, 4:12 AM Sylvain, I couldn't build changing this line of code. But i have succeed using another version of Linux. I have built s52 on Ubuntu 14.04 and on our target platform Astra Linux (based on debian) On Ubuntu i running test/s52glx it displays some data from my file. But in Astra it says /S57data.c:337 in S57_geo2prj3dv(): ERROR: nothing to project to .. load a chart frist! ** ERROR:S57data.c:339:S57_geo2prj3dv: assertion failed: (0) S52.c:1332 in _trapSIG(): Signal SIGABRT(6) cought .. Abort/ -- View this message in context: http://osgeo-org.1560.x6.nabble.com/gdal-dev-Convert-S57-to-image-with-S52-rendering-tp4987897p5159559.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
[gdal-dev] GDAL 1.11 and EPSG:3857
Using GDAL 1.11 When I use the gdalwarp command: gdalwarp -s_srs ESRI::EPG94.prj -t_srs epsg:*900913 *EPG94.ecw 900913.tif I get legitimate gdalinfo with datum and spheroid defined. Driver: GTiff/GeoTIFF Files: 900913.tif Size is 76318, 41566 Coordinate System is: PROJCS[Google Maps Global Mercator, GEOGCS[WGS 84, *DATUM[WGS_1984,* *SPHEROID[WGS 84,6378137,298.257223563,* AUTHORITY[EPSG,7030]], AUTHORITY[EPSG,6326]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433], AUTHORITY[EPSG,4326]], PROJECTION[Mercator_1SP], PARAMETER[central_meridian,0], PARAMETER[scale_factor,1], PARAMETER[false_easting,0], PARAMETER[false_northing,0], UNIT[metre,1, AUTHORITY[EPSG,9001]]] Origin = (13363025.43312920300,-2674166.54959407820) Pixel Size = (0.163524580961778,-0.163524580961778) Metadata: AREA_OR_POINT=Area COLORSPACE=RGB COMPRESSION_RATE_TARGET=9 VERSION=2 Image Structure Metadata: INTERLEAVE=PIXEL Corner Coordinates: Upper Left (13363025.433,-2674166.550) (120d 2'31.56E, 23d29'18.24S) Lower Left (13363025.433,-2680963.612) (120d 2'31.56E, 23d32'40.94S) Upper Right (13375505.302,-2674166.550) (120d 9'15.15E, 23d29'18.24S) Lower Right (13375505.302,-2680963.612) (120d 9'15.15E, 23d32'40.94S) Center (13369265.368,-2677565.081) (120d 5'53.36E, 23d30'59.60S) Band 1 Block=76318x1 Type=Byte, ColorInterp=Red Description = Red Band 2 Block=76318x1 Type=Byte, ColorInterp=Green Description = Green Band 3 Block=76318x1 Type=Byte, ColorInterp=Blue Description = Blue - When I use the gdalwarp command: gdalwarp -s_srs ESRI::EPG94.prj -t_srs epsg:*3857 *EPG94.ecw 3857.tif I get illegitimate gdalinfo with datum and spheroid unknown and unretrievable: Driver: GTiff/GeoTIFF Files: 3857.tif Size is 76318, 41566 Coordinate System is: LOCAL_CS[WGS 84 / Pseudo-Mercator, GEOGCS[WGS 84, *DATUM[unknown,* *SPHEROID[unretrievable - using* PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433]], AUTHORITY[EPSG,3857], UNIT[metre,1]] Origin = (13363025.43312920300,-2674166 Pixel Size = (0.163524580961778,-0.16352458 Metadata: AREA_OR_POINT=Area COLORSPACE=RGB COMPRESSION_RATE_TARGET=9 VERSION=2 Image Structure Metadata: INTERLEAVE=PIXEL Corner Coordinates: Upper Left (13363025.433,-2674166.550) Lower Left (13363025.433,-2680963.612) Upper Right (13375505.302,-2674166.550) Lower Right (13375505.302,-2680963.612) Center (13369265.368,-2677565.081) Band 1 Block=76318x1 Type=Byte, ColorInterp Description = Red Band 2 Block=76318x1 Type=Byte, ColorInterp Description = Green Band 3 Block=76318x1 Type=Byte, ColorInterp Description = Blue This messes up my geoserver image pyramid when I try to use it. - It seems epsg:900913 works but epsg:3857 does not. The thing is, gdalwarp to 3857 worked in gdal 1.10 Thanks, Matt -- View this message in context: http://osgeo-org.1560.x6.nabble.com/GDAL-1-11-and-EPSG-3857-tp5159753.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] GDAL 1.11 and EPSG:3857
Even, Thanks for the quick reply. I am using GDAL from the OSGeo4W suite. I have my gdal_data set to: set GDAL_DATA=C:\OSGeo4W64\share\gdal Matt -- View this message in context: http://osgeo-org.1560.x6.nabble.com/GDAL-1-11-and-EPSG-3857-tp5159753p5159755.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] Can anyone else replicate this bug?
Hello everyone, I unziped this file: http://www12.statcan.gc.ca/census-recensement/2011/geo/bound-limit/files-fichiers/gct_000a11a_e.zip , and then fed the directory into the following command: ogr2ogr -t_srs epsg:4326 -f CSV output.csv canada_census_boundaries/ -lco GEOMETRY=AS_WKT Line 4 ends with ...,-76.52966604442 44.24964776838)),5210015.00,0015.00,521,Kingston,B,35521,35,Ontario but line 5 ends with ...-81.06617526813 42.,5550100.01,0100.01,555,London,B,3,35,Ontario As you can see, the geometry is truncated and the ending quotes are also not applied to it, creating invalid CSV. Would anyone else be able to replicate this, just to ensure this isn't due to something on my system? Thank you, -ravi ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdal-dev Digest, Vol 123, Issue 64
Hello,
I've decided to attached here the five hdf files which I used in stitching.
I just converted into GTiff and warped. Definitely, the two blocks doesn't
meet but I'm just not sure if these covers the middle area as what you've
said. You could give it a try if you can stitch these well.
Thanks!
On Mon, Sep 1, 2014 at 1:40 PM, gdal-dev-requ...@lists.osgeo.org wrote:
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: OGR C API Spy (Even Rouault)
2. Appveyor Windows Continuous Integration (Even Rouault)
3. Re: OGR C API Spy (Robert Coup)
4. Re: OGR C API Spy (Even Rouault)
5. Re: Problem encountered in stitching/merging the raster files
(user_name)
6. Re: Problem encountered in stitching/merging the raster files
(Jukka Rahkonen)
--
Message: 1
Date: Sun, 31 Aug 2014 21:14:15 +0200
From: Even Rouault even.roua...@spatialys.com
To: Robert Coup robert.c...@koordinates.com
Cc: GDAL List gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] OGR C API Spy
Message-ID: 201408312114.15354.even.roua...@spatialys.com
Content-Type: Text/Plain; charset=utf-8
Le dimanche 31 ao?t 2014 20:50:41, Robert Coup a ?crit :
That's cool :) Is there any particular performance penalty to compiling
*with* OGRAPISPY_ENABLED and then running *without*
OGR_API_SPY_FILE/OGR_API_SPY_SNAPSHOT_PATH
set?
Hi Robert,
Hopefully no, see for example :
OGRFeatureH OGR_L_GetNextFeature( OGRLayerH hLayer )
{
VALIDATE_POINTER1( hLayer, OGR_L_GetNextFeature, NULL );
#ifdef OGRAPISPY_ENABLED
if( bOGRAPISpyEnabled )
OGRAPISpy_L_GetNextFeature(hLayer);
#endif
return (OGRFeatureH) ((OGRLayer *)hLayer)-GetNextFeature();
}
I cannot imagine something with less overhead. (if you exclude dynamic
binary
patching techniques ;-) )
OGROpen() and OGR_Dr_CreateDataSource() call a tracing function that tests
if
the env. variable is set, and if so set the boolean bOGRAPISpyEnabled.
Even
Rob :)
On Sun, Aug 31, 2014 at 11:34 PM, Even Rouault
even.roua...@spatialys.com
wrote:
Hi,
This will not be of interest for the crowds, but mainly for OGR driver
developers (and potentially also to get precise bug reports from
users).
I'm
currently adding update capabilities to the MITAB driver, and while
playing with QGIS, there are sometimes sequences of OGR calls that
trigger bugs, but
that I had issues to replicate afterwards. This spy mechanism enables
to
have
recording of all relevant calls to be able to replicate them exactly
afterwards.
Doc to use it : http://www.gdal.org/ograpispy_8h.html
Related autotest script :
http://svn.osgeo.org/gdal/trunk/autotest/ogr/ograpispy.py
Even
--
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
--
Spatialys - Geospatial professional services
http://www.spatialys.com
--
Message: 2
Date: Sun, 31 Aug 2014 21:38:10 +0200
From: Even Rouault even.roua...@spatialys.com
To: GDAL List gdal-dev@lists.osgeo.org
Subject: [gdal-dev] Appveyor Windows Continuous Integration
Message-ID: 201408312138.10607.even.roua...@spatialys.com
Content-Type: Text/Plain; charset=us-ascii
Hi,
I've just experimented with Appveyor, a hosted continuous integration
solution
for Windows to do Windows GDAL builds. This is not completely convincing,
since a optimized build of GDAL, without any optional dependency, takes
more
than 30 minutes, and then gets killed since this is the limit for the free
(as
in free beer) profile... I've managed to make it work with debug builds
that
run in 25 minutes. So no time to run tests. Results can be seen at
https://ci.appveyor.com/project/rouault/gdal-coverage .
This is still interesting since it uses Visual Studio 2013 (a.k.a VC12 /
MSVC
1800), which Tamas doesn't yet use on http://www.gisinternals.com/sdk/
Contrary to Travis-CI, there's no IRC notification yet in Appveyor
unfortunately, so you have to watch the previous mentionned URL. I could
perhaps enable email notices to gdal-comm...@lists.osgeo.org, but did not
do
it for know.
A new build will be launched everytime my cron job runs (i.e. every 15
minutes) *and* something has been committed in SVN.
I've also updated
Re: [gdal-dev] gdal-dev Digest, Vol 123, Issue 64
Hello,
I've decided to attached here the five hdf files which I used in stitching.
I just converted into GTiff and warped. Definitely, the two blocks doesn't
meet but I'm just not sure if these covers the middle area as what you've
said. You could give it a try if you can stitch these well.
Thanks!
A201419704.L2_LAC.SeAHABS.hdf
https://docs.google.com/file/d/0B3MWv8orIhBnbElMVzFTRVktRGc/edit?usp=drive_web
A2014197040500.L2_LAC.SeAHABS.hdf
https://docs.google.com/file/d/0B3MWv8orIhBnWTB5SXF6Skc5djQ/edit?usp=drive_web
A2014197041000.L2_LAC.SeAHABS.hdf
https://docs.google.com/file/d/0B3MWv8orIhBnNko3UWp3ekZHYXc/edit?usp=drive_web
A2014197054000.L2_LAC.SeAHABS.hdf
https://docs.google.com/file/d/0B3MWv8orIhBnd0pqZ0NoblBiLXM/edit?usp=drive_web
A2014197054500.L2_LAC.SeAHABS.hdf
https://docs.google.com/file/d/0B3MWv8orIhBndzdGb1VGZHBta00/edit?usp=drive_web
On Mon, Sep 1, 2014 at 1:40 PM, gdal-dev-requ...@lists.osgeo.org wrote:
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: OGR C API Spy (Even Rouault)
2. Appveyor Windows Continuous Integration (Even Rouault)
3. Re: OGR C API Spy (Robert Coup)
4. Re: OGR C API Spy (Even Rouault)
5. Re: Problem encountered in stitching/merging the raster files
(user_name)
6. Re: Problem encountered in stitching/merging the raster files
(Jukka Rahkonen)
--
Message: 1
Date: Sun, 31 Aug 2014 21:14:15 +0200
From: Even Rouault even.roua...@spatialys.com
To: Robert Coup robert.c...@koordinates.com
Cc: GDAL List gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] OGR C API Spy
Message-ID: 201408312114.15354.even.roua...@spatialys.com
Content-Type: Text/Plain; charset=utf-8
Le dimanche 31 ao?t 2014 20:50:41, Robert Coup a ?crit :
That's cool :) Is there any particular performance penalty to compiling
*with* OGRAPISPY_ENABLED and then running *without*
OGR_API_SPY_FILE/OGR_API_SPY_SNAPSHOT_PATH
set?
Hi Robert,
Hopefully no, see for example :
OGRFeatureH OGR_L_GetNextFeature( OGRLayerH hLayer )
{
VALIDATE_POINTER1( hLayer, OGR_L_GetNextFeature, NULL );
#ifdef OGRAPISPY_ENABLED
if( bOGRAPISpyEnabled )
OGRAPISpy_L_GetNextFeature(hLayer);
#endif
return (OGRFeatureH) ((OGRLayer *)hLayer)-GetNextFeature();
}
I cannot imagine something with less overhead. (if you exclude dynamic
binary
patching techniques ;-) )
OGROpen() and OGR_Dr_CreateDataSource() call a tracing function that tests
if
the env. variable is set, and if so set the boolean bOGRAPISpyEnabled.
Even
Rob :)
On Sun, Aug 31, 2014 at 11:34 PM, Even Rouault
even.roua...@spatialys.com
wrote:
Hi,
This will not be of interest for the crowds, but mainly for OGR driver
developers (and potentially also to get precise bug reports from
users).
I'm
currently adding update capabilities to the MITAB driver, and while
playing with QGIS, there are sometimes sequences of OGR calls that
trigger bugs, but
that I had issues to replicate afterwards. This spy mechanism enables
to
have
recording of all relevant calls to be able to replicate them exactly
afterwards.
Doc to use it : http://www.gdal.org/ograpispy_8h.html
Related autotest script :
http://svn.osgeo.org/gdal/trunk/autotest/ogr/ograpispy.py
Even
--
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
--
Spatialys - Geospatial professional services
http://www.spatialys.com
--
Message: 2
Date: Sun, 31 Aug 2014 21:38:10 +0200
From: Even Rouault even.roua...@spatialys.com
To: GDAL List gdal-dev@lists.osgeo.org
Subject: [gdal-dev] Appveyor Windows Continuous Integration
Message-ID: 201408312138.10607.even.roua...@spatialys.com
Content-Type: Text/Plain; charset=us-ascii
Hi,
I've just experimented with Appveyor, a hosted continuous integration
solution
for Windows to do Windows GDAL builds. This is not completely convincing,
since a optimized build of GDAL, without any optional dependency, takes
more
than 30 minutes, and then gets killed since this is the limit for the free
(as
in free beer) profile... I've managed to make it work with debug builds
that
run in 25 minutes. So no time to run tests. Results can be seen at
Re: [gdal-dev] Can anyone else replicate this bug?
On 2014-09-03 1:24, Ravi Desai wrote: Hello everyone, I unziped this file: http://www12.statcan.gc.ca/census-recensement/2011/geo/bound-limit/files-fichiers/gct_000a11a_e.zip , and then fed the directory into the following command: ogr2ogr -t_srs epsg:4326 -f CSV output.csv canada_census_boundaries/ -lco GEOMETRY=AS_WKT Line 4 ends with ...,-76.52966604442 44.24964776838)),5210015.00,0015.00,521,Kingston,B,35521,35,Ontario but line 5 ends with ...-81.06617526813 42.,5550100.01,0100.01,555,London,B,3,35,Ontario As you can see, the geometry is truncated and the ending quotes are also not applied to it, creating invalid CSV. See the post OGR v1.11 CSV GEOM=AS_WKT truncated..., at http://lists.osgeo.org/pipermail/gdal-dev/2014-June/thread.html The issue has been fixed already: r27434 | rouault | 2014-06-04 21:38:05 +0200 (Wed, 04 Jun 2014) CSV: fix to avoid truncation of WKT geometries to 8000 characters I also mentioned a work-around in my reply back then. Hermann ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
