Re: [gdal-dev] gdal_translate with -projwin possible bug
Lauren O'Brien gmail.com> writes: > > > Hello all, > > I've noticed what I think may be a bug with gdal_translate, just looking for further information before deciding whether to report it. > > In version 1.11.4 and earlier, using the -projwin tag to subset a raster produces an output whose cell alignment and content matches the source dataset - it just grabs any cells that intersect the box and writes them to the output. I am sure that there are also users who consider that it is a bug if the output does not exactly match -projwin. I would have a try with gdalwarp by using -te and -tap together. I believe that you would like to see something like -tap (target aligned pixels) also in gdal_translate. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Tickets that mention e00
Hi, I wonder how likely it is that the tickets dealing with Arc/Info coverages http://www.gdal.org/drv_avce00.html will still receive some bug fixes. Would it be a big mistake to close them all as won't fix? -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Time for a new GeoJSON driver?
Even Rouault spatialys.com> writes: > - right hand rule of polygons Which means actually left hand rule if I have understood the right hand/left hand rules correctly. If you walk along the polygon rings the name of the rule is telling where the interior of the polygon is. If you follow the outer ring that is winding counterclockwise the interior in on your left hand side. I may be wrong. And the rule does not explicitly say anything about people walking backwards. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Create a new shapefile using ogr utilities
Andrea Peri gmail.com> writes: > > Hi, > is possible create a new empty shapefile using the ogr utilities. > > I search and try using ogrinfo and a sql like "create table ..." but > without any success. ogr2ogr -f "ESRI Shapefile" -dialect sqlite -sql "select geometry from foo where 1=2" emptypoint.shp foo.shp -nlt point Requires foo.shp to exist so not perfect. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] GDAL reads ESRI MultiLinestring as simple Linestring
Hi,
I was reading the documentation of ESRI json from
http://resources.arcgis.com/en/help/rest/apiref/geometry.html and this
example seems to be about a MultiLinestring with two parts:
A 2D polyline
{
"paths" : [
[ [-97.06138,32.837], [-97.06133,32.836], [-97.06124,32.834],
[-97.06127,32.832] ],
[ [-97.06326,32.759], [-97.06298,32.755] ]
],
"spatialReference" : {"wkid" : 4326}
}
However, GDAL reads the geometry as a single Linestring when I bake the
paths inside a json document. I wrote the document by hand and I am not sure
if it is correct but at least GDAL reads it:
{
"geometryType": "esriGeometryPolyline",
"spatialReference": {
"wkid": 4326,
"latestWkid": 4326
},
"fields": [
],
"features": [
{
"attributes": {
},
"geometry": {
"paths" : [
[ [-97.06138,32.837], [-97.06133,32.836], [-97.06124,32.834],
[-97.06127,32.832] ],
[ [-97.06326,32.759], [-97.06298,32.755] ]
],
"spatialReference" : {"wkid" : 4326}
}
}
]
}
-Jukka Rahkonen-
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] JP2 Segfault
Yves Jacolin free.fr> writes: > > Jukka, I did not use two --config flags at the same time, but this information > is a great confirmation how to manage such multi config flag, definitively useful > for next time. Hi Yves, I was carefully reading your first mail which did have two --config flags in the debug info but perhaps it was just a copy-paste error: Starting program: /usr/local/bin/gdal_translate --config GDAL_SKIP JP2ECW -- config GDAL_SKIP ECW -a_srs EPSG:2154 -co BIGTIFF=IF_SAFER -co COMPRESS=JPEG - co TILED=YES -co PHOTOMETRIC=YCBCR ORTHO_EXPRESS_2015.vrt ORTHO_EXPRESS_2015.tif -Jukka- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] JP2 Segfault
Yves Jacolin free.fr> writes: > > Hello, > > I am working on some JP2 data (total 262 Go) . I started creating a vrt file > and then "gdal_translate" them. > > I always have a segfault. I tried to use a GDAL_SKIP config to use another > driver but it seems that I can successfully do this: > > >> Stack trace in bt << > > Starting program: /usr/local/bin/gdal_translate --config GDAL_SKIP JP2ECW -- > config GDAL_SKIP ECW -a_srs EPSG:2154 -co BIGTIFF=IF_SAFER -co COMPRESS=JPEG - > co TILED=YES -co PHOTOMETRIC=YCBCR ORTHO_EXPRESS_2015.vrt > ORTHO_EXPRESS_2015.tif ... clip ... > Using --config GDAL_SKIP ECW doesn't change anything. > > I can't understand two things: > > * first: why libNCSEcw is used instead of openjpeg200 lib? You have used two times the GDAL_SKIP config option --config GDAL_SKIP JP2ECW --config GDAL_SKIP ECW In https://trac.osgeo.org/gdal/wiki/ConfigOptions#GDAL_SKIP it is documented that for skipping several drivers a comma separated list is needed: "The value of this option must be a space delimited list of the short name of the GDAL drivers to unregister." I suppose that with your command only the ECW driver gets skipped and that is not for JPEG2000 at all. Using just one option (or a list) as --config GDAL_SKIP JP2ECW should help you. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Does "OGR_STYLE from rivers" mean it will read rivers.ofs ?
積丹尼 Dan Jacobson jidanni.org> writes:
>
> Maybe http://www.gdal.org/ogr_feature_style.html is just a framework
> and not something that is implemented anywhere?
>
> Are there any examples of anybody using LABEL(f:"Times New
> Roman",s:12pt,t:{text_string}) to print anything anywhere?
Most GIS formats do not support per feature styles. OGR_STYLE should be
usable in formats like MapInfo, KML, DXF, PDF vector. PDF might be easiest
for testing.
-Jukka Rahkonen-
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] How to escape "desc" with OGR SQL?
Even Rouault spatialys.com> writes: > On Windows shell I suppose ? Perhaps with \" (not tried) > > ogrinfo -sql "select attr_2 as \"desc\" from test" test.shp This really works for me on Windows. > On Linux bash the following - using single quote for the full SQL - also works > (not sure on Windows) For sure does not work on Windows. > ogrinfo -sql 'select attr_2 as "desc" from test' test.shp > > > ERROR 1: SQL Expression Parsing Error: syntax error, unexpected DESC, > > expecting identifier. Occurred around : > > select attr_2 as desc from test > > ^ > > I managed to do the job with SQLite dialect but I wonder if I found a bug > > with using "desc" as an identifier. > > Probably SQLite is more tolerant about using reserved keywords in non- > ambiguous situations. Ahh, I understand now. If I write just "desc" the double quotes are actually removed but SQLite does not care in this case. But I can't do select... as "union" because now SQLite complains ERROR 1: In ExecuteSQL(): sqlite3_prepare(select attr_2 as union from test): near "union": syntax error I must write it escaped select... as \"union\" instead so that double quotes are protected. Are there other characters than " which may need escaping? I guess % and _ but probably there are more. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] How to escape "desc" with OGR SQL?
Hi, I had a need to convert some data into GPX format and populate the GPX attributes "name" and "desc". Name was not any problem as can be tested with ogrinfo -sql "select attr_1 as name from test" test.shp However, "desc" is a SQL keyword for descending order and all my trials with OGR SQL failed like this: ogrinfo -sql "select attr_2 as "desc" from test" test.shp ERROR 1: SQL Expression Parsing Error: syntax error, unexpected DESC, expecting identifier. Occurred around : select attr_2 as desc from test ^ I managed to do the job with SQLite dialect but I wonder if I found a bug with using "desc" as an identifier. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Is option --utility_version documented?
Hi, I noticed an utility program option --utility_version from https://trac.osgeo.org/gdal/changeset/34340. Am I right that this option does not appear in any user documentation? If not I would like to add it into http://gdal.org/ogr_utilities.html and http://gdal.org/gdal_utilities.html Option returns for example "gdalinfo was compiled against GDAL 2.1.0dev and is running against GDAL 2.1.0dev" Is it possible the compile and runtime versions are different? What can lead to such situation, and what trouble it makes? -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] New driver implementation with larger block size
Javier Calzado ericsson.com> writes: > > Thanks for your answer Even, > > I knew about GDAL_ONE_BIG_READ, but given that our tool will access > several raster simultaneously and will perform intensive operations with > them, I like the idea of allowing GDAL caching blocks, as long as cache > hits rate is high, this will increase performance I guess. GDAL cache is > pretty smart and well done, this way we avoid re-implementing our own > custom cache system. Besides that, we will do intensive access to raster > on a pixel basis, and it seems that performance, according to some tests I > did, is highly improved using direct block pointers (GetLockedBlockRef) > over RasterIO pixel access. So, unless I am missing something with > RasterIO, I think we will go for the cached block access method. > > So, I guess the only way to accomplish larger block sizes in my new driver > is to implement a custom rasterband derived from GDALRasterBand and > implement IReadBlock/IWriteBlock methods, right? > > My concern in that case is ... what would happen with blocks that cannot > be completely filled with raster data? I mean, given a 150x150px raster > for example, if a define block size as 150x100, the second block will have > the last 50 scanlines empty, does GDAL internally handle this situation > properly? Hi, Unfortunately I do not really understand what you are talking about but when I saw words "blocks" and "caching" I started to think that the same words appear in Ari Jolma's raster algebra https://trac.osgeo.org/gdal/wiki/rfc62_raster_algebra Could there be some overlaps? -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] PostGIS Out of db VRT containing JPEG2000 GDAL 2.1 OpenJPEG
bboughton gmail.com> writes: > > Thanks for your suggestions. > > SELECT short_name FROM ST_GDALDrivers(); > Lists VRT, GTiff, JPEG2000 etc as a supported formats > Hi, Driver JPEG2000 means the Jasper driver which is rather useless for geospatial images http://www.gdal.org/frmt_jpeg2000.html. Do you see also driver JP2OpenJPEG listed http://www.gdal.org/frmt_jp2openjpeg.html? -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Spatial index to raster VRT
Even Rouault spatialys.com> writes: > > On Thursday 26 May 2016 13:26:38 Jukka Rahkonen wrote: > > > > VRT supports one overview, but that can itself be a VRT, which in turn can > > point to next VRT overview and so on. > Actually, this is not true (although I might have in the past say so). The doc > currently states : > """ > Overview: This optional element describes one overview level for the band. It > should have a child SourceFilename and SourceBand element. The SourceFilename > may have a relativeToVRT boolean attribute. Multiple elements may be used to > describe multiple overviews. > """ > > and I've verified it works (at least they are reported by gdalinfo) Confirmed by adding several tiff files with increasing pixel size as Overview elements into the same VRT. Works fine. Still missing the main thing - spatial index for making access to small region fast with thousands or images in VRT. -Jukka- > > Even > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] How to recognize FDO style SQLite db?
Even Rouault spatialys.com> writes: > This probably doesn't completely fullfil the requirement of "simple mean" , > but if you enable the debug messages from GDAL with "--debug on", you should > see : > "OGR style SQLite DB found !" > > whereas a Spatialite one will trigger : > "SpatiaLite v4 DB found !" (or "Spatialite DB found" for spatialite 2 or 3) Simple enough, I'll try to find some place to document that in http://www.gdal.org/drv_sqlite.html. -Jukka- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] How to recognize FDO style SQLite db?
Hi, User in gis.stackoverflow tried to use SQL "select ST_Union(geometry)" for the Natural Earth SQLite db file from http://naciscdn.org/naturalearth/packages/natural_earth_vector.sqlite.zip. The query yields an empty geometry because the NE database is written with FDO geometries instead of SpatiaLite geometries. What I wonder is that does GDAL user have any simple mean for getting informed if SQLite db is FDO or Spatialite. If SpatiaLite is present a clever enough user can use ogrinfo and check from https://www.gaia-gis.it/gaia-sins/spatialite-sql-latest.html#p16fdo that value 2 is returned in case when "both tables exist, and their layout is the one used by FDO/OGR" ogrinfo -sql "select CheckSpatialMetaData()" natural_earth_vector.sqlite INFO: Open of `natural_earth_vector.sqlite' using driver `SQLite' successful. Layer name: SELECT Geometry: None Feature Count: 1 Layer SRS WKT: (unknown) CheckSpatialMetaData(): Integer (0.0) OGRFeature(SELECT):0 CheckSpatialMetaData() (Integer) = 2 However, the one who knows to do that must be somewhat advanced GDAL and Spatialite user. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] EPSG code not recognized from GeoTiff written by GDAL
Blumentrath, Stefan nina.no> writes: > Hei, > > We are facing issues with GeoTiffs that were written by GDAL, after importing them to GeoServer or opening in Desktop GIS. > On file was produced in GRASS and exported using r.out.gdal (GDAL 2.1dev), the other file in R, using rgdal (GDAL2.0.x) with EPSG code 25832. > The rasters seem to miss the AUTHORITY parameter... > > QGIS for example detects EPSG 3044 (which is technically identical), and GeoServer considers the CRS as invalid (because of this: > http://docs.geonode.org/en/master/tutorials/advanced/geonode_production/adv_gsconfig/crs_handling.html). > > Did anyone else experience the same? Hi, From my GDAL 2.1-dev gdalsrsinfo epsg:25832 PROJ.4 : '+proj=utm +zone=32 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_de fs ' OGC WKT : PROJCS["ETRS89 / UTM zone 32N", GEOGCS["ETRS89", DATUM["European_Terrestrial_Reference_System_1989", SPHEROID["GRS 1980",6378137,298.257222101, AUTHORITY["EPSG","7019"]], TOWGS84[0,0,0,0,0,0,0], AUTHORITY["EPSG","6258"]], PRIMEM["Greenwich",0, AUTHORITY["EPSG","8901"]], UNIT["degree",0.0174532925199433, AUTHORITY["EPSG","9122"]], AUTHORITY["EPSG","4258"]], PROJECTION["Transverse_Mercator"], PARAMETER["latitude_of_origin",0], PARAMETER["central_meridian",9], PARAMETER["scale_factor",0.9996], PARAMETER["false_easting",50], PARAMETER["false_northing",0], UNIT["metre",1, AUTHORITY["EPSG","9001"]], AXIS["Easting",EAST], AXIS["Northing",NORTH], AUTHORITY["EPSG","25832"]] Do you get the same result? If you do I wonder why AUTHORITY is not written into GeoTIFF. -Jukka Rahkonen- > > Kind regards, > Stefan ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Spatial index to raster VRT
Daniel Morissette mapgears.com> writes: > > On 2016-05-26 8:40 AM, Jukka Rahkonen wrote: > > Hi, > > > > Any thoughts about alternatives to implement the feature request from > > https://trac.osgeo.org/gdal/ticket/5762? > > > > What I dream of is to be able to utilize all the nice on-the-fly tweaks that > > can be done with VRT at similar speed that Mapserver is reaching with tileindex. > > > > That would be a nice enhancement. As usual I guess we need a champion > and/or some funding to make this happen. > > I came across a similar use case not long ago and realized that to get > top performance at all zoom levels we'd also need the ability to > associate overviews with the VRT. I didn't check if creating external > overviews with gdaladdo would work for a VRT already. Maybe it does? It does and is even documented in http://www.gdal.org/gdal_vrttut.html#gdal_vrttut_overviews. VRT supports one overview, but that can itself be a VRT, which in turn can point to next VRT overview and so on. Easier than to explain is to give a link to this old experiment http://latuviitta.org/documents/GDAL_Scale_dependent_VRT_test.zip Unzip and open the best resolution VRT t0320.vrt with QGIS, zoom in, and you should see how 5 different tiff files with different pixel size and rendering styles behave. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Spatial index to raster VRT
Hi, Any thoughts about alternatives to implement the feature request from https://trac.osgeo.org/gdal/ticket/5762? What I dream of is to be able to utilize all the nice on-the-fly tweaks that can be done with VRT at similar speed that Mapserver is reaching with tileindex. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Get a List of tiles source name from the gpkg_content
Gane R gmail.com> writes: > > > > I see the usage of the gdalinfo for the gpkg with multiple tile source as Subdataset, > > > I also saw the source code of gdalinfo getting the subdataset > > Q1: Can I get a list of tiles source name (table_name) in gpkg_contents data_type as tiles? Hi, I am not sure if I understood what you mean, but GeoPackage is a database and you can use SQL and ogrinfo for doing anything that is possible with SQL. ogrinfo test.gpkg -sql "select table_name, data_type from gpkg_contents where data_type='tiles'" INFO: Open of `test.gpkg' using driver `GPKG' successful. Layer name: SELECT Geometry: None Feature Count: 2 Layer SRS WKT: (unknown) table_name: String (0.0) data_type: String (0.0) OGRFeature(SELECT):0 table_name (String) = one data_type (String) = tiles OGRFeature(SELECT):1 table_name (String) = two data_type (String) = tiles -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] VRT and M-dimension - any example?
Hi, Release notes https://trac.osgeo.org/gdal/wiki/Release/2.1.0-News announce that RFC 61: Support for measured geometries is implemented in VRT. However, this is not mentioned in http://www.gdal.org/drv_vrt.html. I would like to improve the documentation but before I can do that I need to understand how it works. Could somebody help a bit with making a valid VRT for - CSV source - GeometryType>wkbPointZM - GeometryField encoding="PointFromColumns" Or are the PointFromColumn attributes simply x="x" y="y" z="z" m="m" ? -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] More simplification algorithms
Hi, I noticed this question in gis.stackexchange http://gis.stackexchange.com/questions/192547/generalization-algorithms and the answer lead to this this "psimpl" library http://psimpl.sourceforge.net/. The library is MPL 1.1 licensed. Is the license suitable for GDAL and aculd we have any use for the library and alternative simplification methods in GDAL? -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Layer intersection: two polygons with a common point
Ari Jolma gmail.com> writes: > > > 28.04.2016, 14:17, Even Rouault kirjoitti: > > > > > > > > I'm still thinking that some option to ensure we don't try to feed the output > > layer with an incompatible geometry would be useful. > > I'm of that opinion too. It may be too late to make "real intersection" > the default and with some option like > "filter-features-with-different-geometry-type" to make it filter unlike > features off but an option would be a good idea. Finding points where streams meet lakes or routes go through parking areas are realistic use cases so at least it would be good to make is possible to find them with GDAL somehow. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Layer intersection: two polygons with a common point
Even Rouault spatialys.com> writes: > > Le jeudi 28 avril 2016 08:50:46, Ari Jolma a écrit : > > Jukka pointed out this > > > > http://gis.stackexchange.com/questions/191336/gdal-ogr-ogr-layer-intersecti > > on-producing-points-from-linestrings > > > > to me. > > > > It is true that intersecting two layers, where one contains > > > > 'POLYGON (( 140 360, 140 480, 220 480, 220 360, 140 360 ))' > > > > and the other > > > > 'POLYGON (( 220 260, 220 360, 300 360, 300 260, 220 260 ))' > > > > produces an empty layer. The reason is a check > > > > (z_geom->IsEmpty() || > >(x_geom->getDimension() == 2 && > > y_geom->getDimension() == 2 && > > z_geom->getDimension() < 2)) > > > > (x and y are the polygons and z is the intersection, a point in this > > case), which leads to discarding the point. > > > > I believe this check was introduced as a result of ticket 4772 > > > > https://trac.osgeo.org/gdal/ticket/4772 > > > > in changeset 25427, where it is stated that "when intersecting 2 > > polygons, do not consider a point or linear intersection as a valid one". > > Oh I see we are both involved in this The advantage of the current > behaviour is that it is compatible with most popular output formats that don't > like mixing geometry types in the same layer (think of shapefiles, and > generally postgis, spatialite when layer geometry type is not unknown, ...). > Perhaps one possible approach would be to check the output layer geometry type > : if it is wkbUnknown, keep all non empty geometries, otherwise only keep > those compatible of the geometry type. And perhaps combine that default > behaviour with an option to the method "KEEP_LOWER_DIMENSION_GEOMETRIES" > (would be honoured only if output layer geometry type == wkbUnknown) ? Since I > feel that in most cases and in real-life, intersection of polygons resulting > in points or lines should not happen. > Hi, I would say that the current behaviour is OK but it should not be called as "Intersection" because it is so clearly against the OGC Simple Feature Access - SQL option. There is even a conformity test number 47 on page 63 that takes a linestring and a polygon as inputs and requires a point as an output. PostGIS, Spatialite and Oracle are also all returning point for this query. The test in the standard is: T47 Intersection(g1 Geometry, g2Geometry) : Geometry For this test, we will determine the intersection between Cam Stream and Blue Lake. The answer must be 'POINT( 52 18 )' Instead of adding a new weird configuration options, how about having an OGC compliant function "Intersects" and our our extension "IntersectsProperly" like there is ContainsProperly in PosGIS http://postgis.net/docs/ST_ContainsProperly.html -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Promote 2.1.0RC3 for release
Even Rouault spatialys.com> writes: > > Motion: GDAL/OGR 2.1.0RC3 is promoted to be the official 2.1.0 final release. +1 -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Resampling a raster file with GDAL C#
Didier Bernard hotmail.com> writes: > Are you suggesting to simply convert the .tif file from command prompt by using gdal_translate? Like so: > > "C:/gdalwin32-1.4.1/bin/gdal_translate.exe" -of VRT "C:/vesuvius_wgs84.tif" "C:/vesuvius_wgs84.vrt" > > ? > > And "build" my .vrt file according to: C:/vesuvius_wgs84.vrt? > That won't help me for other .tif files Of course it will help you with all files. When you know what you need to do with one image you know what you need to do with any other image. Do something like this: Take a test image, for example 88x88 pixels. Run these commands: gdal_translate -of vrt 88.png 88.vrt gdal_translate -outsize 50% 50% -of vrt 88.png 44.vrt Check the result: gdalinfo 88.vrt Driver: VRT/Virtual Raster Files: 88.vrt 88.png Size is 88, 88 Pixel Size = (1.000,-1.000) gdalinfo 44.vrt Driver: VRT/Virtual Raster Files: 44.vrt 88.png Size is 44, 44 Pixel Size = (2.000,-2.000) All right, the result is correct, double pixel size and half of the width and height. Now have a look at the vrt files, find what is essential and learn to build similar ones from code. 88.vrt 9.9500e+001, 1.e+000, 0.e+000, 1.0050e+002, 0.e+000,-1.e+000 Red 88.png 1 44.vrt 9.9500e+001, 2.e+000, 0.e+000, 1.0050e+002, 0.e+000,-2.e+000 PIXEL Red 88.png 1 Find the differences: The latter seems to differ here: and here 9.9500e+001, 2.e+000, 0.e+000, 1.0050e+002, 0.e+000,-2.e+000 and here: I am not a programmer but obviously you are and because programmers tend to be good at doing some small calculations with numbers I am sure that you can - find SourceProperties (here RasterXSize="88" RasterYSize="88") - devide by 2 and feed values to VRTDataset rasterXSize and rasterYSize - feed the same numbers to DstRect xSize and ySize - double the pixel size in 2nd and 6th terms of GeoTransform -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Shapefile to SQL Server
Bo Victor Thomsen gmail.com> writes: > > > The shape file in the zip is not in projection espg:4269. It's in > utm zone 12N. Replace the "-a_srs", "ESPG:4269" with "-t_srs", > "ESPG:4269" and "-s_srs", "ESPG: code_for_UTM_12N" > This causes ogr2ogr to reproject you data to the correct projection And it is written "EPSG" as in European Petroleum Survey Group. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Rectify TIFF: Difference between applied GCP and warped image
Bischof, Richard lgln.niedersachsen.de> writes: > > Hi Jukka, > > you're correct. ArcMap is doing the on-the-fly transformation with the dataset, I applied the gcps using > gdal_translate to. > With both gdal_warp and ArcMap Rectify I use second order polynomial. > > I also found, that some areas of my source image are cut out from the gdal_warp destination dataset. > Hi, I can't really help you but because I do not understand warping algorithms. If ArcMap and GDAL makes different output with 2nd order polynomial and with the same gcp set I can see three alternatives: 1) GDAL is wrong 2) ArcMap is wrong 3) There are different interpretations about what should happen and both are right, or wrong. I suppose that what GDAL is doing is written in https://trac.osgeo.org/gdal/browser/trunk/gdal/alg/gdaltransformer.cpp I fear we do not have the code used by ArcMap available for making a comparison. Can you simplify the case into a question like: With this gcp set, applied to an image of sixe xxx(W) by yyy(H) pixels, after 2nd order polynomial transformation with GDAL the source pixel (x1, y1) is moved into location (x2, y2) in pixel space, and (xxx(E), yyy(N)) in projected cooordinates in EPSG:. ArcMap moves this pixel into (x2', y2') (xxx'(E), yyy'(N)) and I think than one or the other is wrong. What do warping specialists think? -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Rectify TIFF: Difference between applied GCP and warped image
Bischof, Richard lgln.niedersachsen.de> writes: > > Hello there, > > I`m trying to rectify a lots of dataset in tiff format using gdal. I'am using Windows 7 Professional, gdal > 1.11.2 . > > My steps / commands are: > ... SNIP ... > F:\Projekt\gross\106300.tif D:/temp.tif > > 2) Warp the image using gdalwarp > gdalwarp -multi -wm 4000 -overwrite -r bilinear -order 2 -co COMPRESS=NONE -co TFW=YES -co TILED=YES > D:/temp.tif D:\GDAL\106300.tif > > My problem is, that the output dataset from the second step is not what I expected. It is warped different, > than ArcMap is showing me, when I load the output dataset from the first step. (Including the gcp). > > What am I missing in my gdalwarp command? Do you mean that ArcMap is doing on-the-fly warping by the ground control points? Do you know which warping method it is applying then? If it is using 2nd order polynomial then the results should be close your result after the second step, if something else then not necessarily. Can you warp the image physically with ArcMap so that you force it to use the 2nd order polynomial? -Jukka Rahkonen- > Thank you! > > Mit freundlichen Grüßen > Richard Bischof > > Landesamt für Geoinformation und Landesvermessung Niedersachsen (LGLN) > - Regionaldirektion Hameln-Hannover - > Dezernat 2 - Geodatenmanagement > Constantinstraße 40, 30177 Hannover > Tel.: +49 511 30245-314 > Fax: +49 511 30245-360 > mailto:richard.bischof lgln.niedersachsen.de > www.lgln.de/rd-hm > > ___ > 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] Use of gdalwarp to make GeoTiff transparent is flipping the image
Liglio pobox.com> writes: In your original file you have > Origin = (-58.44952010001,-34.57139910001) > Pixel Size = (0.020016536493374,0.020014199367660) In the converted one you have > Origin = (-58.44952010001,-12.395666200632341) > Pixel Size = (0.020015227575895,-0.020015227575895) Notice the positive offset for the y coordinate in the original which means that actually it is a south-up image and latitude is growing when you go downwards from the up-most row of the image. Gdalwarp is turning the image into common north-up image which is also changing the origin because the native origin is now in the bottom-left corner. If the original image is not really a south-up one then it has wrong georeferencing. Gdalwarp is doing what it is supposed to do. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Use of gdalwarp to make GeoTiff transparent is flipping the image
Liglio pobox.com> writes: > > Hi, > > I used the command "gdalwarp -dstalpha -srcnodata 255 -dstnodata 0 image.tif > transp_image.tif" to make a color GeoTiff Image became transparent, but it > is flipping the image horizontally. What I am doing wrong? Can I unflipp the > image? > > Thanks. > > <http://osgeo-org.1560.x6.nabble.com/file/n5255474/image299.png> > <http://osgeo-org.1560.x6.nabble.com/file/n5255474/transp_image.png> Could you add the gdalinfo report of the original and warped image? -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] WMS Driver defaulting to version 1.1.1
Passmore, James H. bgs.ac.uk> writes: > > I agree with all those that think that a request like > http://myservice/ows?service=WMS=GetCapabilities; should return the highest supported > version of WMS on that server (currently 1.3.0 but in the near? future 1.4.0 and then 2.0.0...). This is the > expected behaviour according the to the WMS specifications (indeed most OGC services I think), so it > feels a bit wrong to deliberately go against it (so much for standards). > > Supplying the optional version number > http://myservice/ows?service=WMS=GetCapabilities=1.1.1; doesn't actually > guarantee a response in that version either, it's just a preference in the opening negotiation; it only > should be honoured if the server can support that version. I might agree with James if the request is sent without explicit version number. However, I would deny such requests and the whole theoretically brilliant negotiation system by making the version tag compulsory in the XML description file http://www.gdal.org/frmt_wms.html. The version number lottery makes is much harder for the average users to find out what goes wrong when something goes wrong between the client and server. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] osmconf.ini
Frank Broniewski gmail.com> writes: > > > > > > Hi, > I am having some trouble understanding, when - or how - multilinestrings are imported into PostGIS. I am interested in hiking routes from OpenStreetMap and I try to figure out how I can load them correctly into PostGIS. The corresponding OSM Wiki page would be this: http://wiki.openstreetmap.org/wiki/Hiking ,especially the part called "Tagging walking and hiking Route Networks". There should be more hiking routes as relations in my test region e.g. http://www.openstreetmap.org/relation/2827792 is missing. It is not quite clear to my how ogr2ogr decides what kind of data is put into which table. > So, what do I have to do to import this relation into the multilinestrings table? Please find my osmconf.ini attached to this email for further reference. > > BTW, this is with GDAL 1.11.3, released 2015/09/16, on Windows 10 provided by OSGeo4W. > > Many thanks, > Frank > > Attachment (osmconf.ini): application/octet-stream, 3757 bytes By quick look your osmconf.ini is OK, there is "route" along the multilinestring attributes and data contain tag "route=hiking". Could you put a complete, hopefully small sample of OSM data with hiking routes that could be used for testing somewhere for downloading? -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Get EPSG code from WKT
Gane R gmail.com> writes: > When I try to convert to different projection using the gdalwarp without specifying the -s_srs option it reprojects to a different location, for some raster it projects to a correct location. > > But when try to run gdalinfo and I see a lot of EPSG code, when I use the last AUTHORITY EPSG code as -s_srs option the above mention problem is solved. > > Is it that I have use the last AUTHORITY EPSG code or any thing will help > > Expecting your suggestion Expecting some sample data that could be used for reproducing the problem. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Resample elevation GeoTiff to 1 meter resolution.
Ilanit Karpassi defensoft.com> writes: > Hi, > > I > need to resample any resolution GeoTiff with Z heights, to 1 meter per pixel GeoTiff. I > need a Z value in each pixel according to the algorithm > > If > I use GDAL_Warp, . (using the C++ code) it seems that it does that with 0 > values to all pixels. > > Can > you give me a good advice please? So you have written an algorithm in C++ and it converts all Z values into zeroes? Why not to show your code? As a non-programmer I would resample the GeoTIFF first with "gdalwarp -tr 1 1" and continue then with gdal_calc.py http://www.gdal.org/gdal_calc.html -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] MapInfo and number format limits
Jukka Rahkonen maanmittauslaitos.fi> writes: > > Hi, > > This question > http://gis.stackexchange.com/questions/180627/qgis-ogr-shp-to-tab-export-crashing-mapinfo-due-to-number-format-issues > and a referred forum topic > https://groups.google.com/forum/#!topic/mapinfo-l/sO-wcp9bnuQ claim that > MapInfo format allows number format to be 20,16) or shorter. Is this known > and should the mitab driver handle the case? The best specification about MapInfo format that I found is this official MapInfo document http://resource.mapinfo.com/static/files/document/1074660800077/interchange_file.pdf The document does define "decimal" datatype but unfortunately it does not tell which are the accepted values for "width" and "decimals" Columns Specify the number of columns. Then, for each column, create a row containing the column name, the column type, and, for character and decimal columns, a number to indicate the width of the field. Valid column types are: • char (width) • integer (which is 4 bytes) • smallint (which is 2 bytes, so it can only store numbers between -32767 and +32767) • decimal (width,decimals) • float • date • logical -Jukka- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] MapInfo and number format limits
Hi, This question http://gis.stackexchange.com/questions/180627/qgis-ogr-shp-to-tab-export-crashing-mapinfo-due-to-number-format-issues and a referred forum topic https://groups.google.com/forum/#!topic/mapinfo-l/sO-wcp9bnuQ claim that MapInfo format allows number format to be 20,16) or shorter. Is this known and should the mitab driver handle the case? -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Ogrinfo, WKT and geometries with Z
Hi, Ogrinfo is printing the WKT of XYZ geometries this way: ogrinfo polygonz.gpkg -al INFO: Open of `polygonz.gpkg' using driver `GPKG' successful. Layer name: polygonz Geometry: Unknown (any) Feature Count: 1 Extent: (340.00, 420.00) - (560.00, 580.00) Layer SRS WKT: (unknown) FID Column = fid Geometry Column = geom OGRFeature(polygonz):1 POLYGON ((340 580 1,560 580 2,560 420 3,340 580 1)) In "OpenGIS® Implementation Standard for Geographic information - Simple feature access - Part 1: Common architecture" POINT is defined as 2 dimensional. Wouldn't the right WKT be POLYGON Z ((340 580 1,560 580 2,560 420 3,340 580 1)) ? I have tested that some software like OpenJUMP and PostGIS do accept POLYGON with 3 coordinates while some other like Spatialite do not. Because Ari is now working with XYZ(M) code would this also be worth a review? -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RFC 61: Call for vote on adoption
Ari Jolma gmail.com> writes: > > > One more issue came up. > Shapefiles, which have Z will also have M, at least a placeholder > for it. > Having shapefiles as XYZM always in that case may be problematic. > It is possible to use the open options SHPT=type to override the > default. We could have Z => XYZ as default for backwards > compatibility and require open option for Z => XYZM. > Ari09.02.2016, 17:07, Ari Jolma kirjoitti: I noticed your changeset and I was just reading the shapefile specification. I never knew that there are no separate XYZ and XYZM shapetypes. I also believe I have never met a shapefile that really contains XYZM data. I agree that the default should be to convert such shapefiles to XYZ instead of XYZM. That would affect shapetype values 11 PointZ 13 PolyLineZ 15 PolygonZ 18 MultiPointZ -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] shp to raster
Paulo Pires gmail.com> writes: > > Hello > > I try to use: gdal_rasterize -a xxx -burn 255 -burn 0 -ts 3000 3000 -l xxx > aaa.shp bbb.tif for create raster from line shapefile but the output is a > black raster... > > Something is wrong on my command line? Hi, I suppose that the command is planned to take the burn value either from an attribute with -a or from user given values with -burn. Your command has -a and two -burn parameters. You do not have -b parameters for defining the bands. I recommend to read http://www.gdal.org/gdal_rasterize.html again and test with the first example command. Once you see that it works change the parameters one by one to fine tune the result. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RFC 61: Call for vote on adoption
Ari Jolma gmail.com> writes: > > > I'd like to ask the PSC and others to vote on adopting RFC 61: > > Support for measured geometries. +1 -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] How to append to all layers with ogr2ogr?
Hi, I would like to collect data from a bunch of GML files into one GeoPackage but GML files may contain more than 20 layers and ogr2ogr does not want to append data for me because the -append switch probably has an effect only to one explicitly given layer. ogr2ogr -f gpkg -update -append mtk.gpkg /vsizip/K2433L_mtk.zip ERROR 1: Layer Kunta already exists, and -append not specified. Consider using -append, or -overwrite. ERROR 1: Terminating translation prematurely after failed translation of layer Kunta (use -skipfailures to skip errors) Is it reasonable to imagine that there could be an "append_all" switch which would allow appending to all the layers in the target datastore? -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Call for discussion about RFC 61: Support for measures in geometries
Ari Jolma gmail.com> writes: > Should storing data, with measures, into a format, which does not > support measures, remove M values from the data? This would be similar > to the current behavior with curved geometries and formats which do not > support them. I wonder what should happen when GDAL creates new vertices. It does not seem to be clear even with XYZ as can be seen from this example: Take LINESTRING ( 184 389 0, 858 346 100 ) Run ogr2ogr with -segmentize 1 Result: The first vertex of the new linesting has Z=0, all the other vertices have Z=100. With XYZ data users might be happy if Z value gets interpolated just like X and Y but for measurements it could be not desired at all. Does M dimension support anything like NoData? There must be also other cases when GDAL can create unexpected M values but probably we can only warn users about that in the documentation. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Maximum geometry size for JML driver
Even Rouault spatialys.com> writes: > Hi Jukka, > > could you provide the file or the source file used to generate it ? In theory, > the driver should be able to process any valid file. The checks are meant to > detect things like > that could result in denial of service, but there must be something wrong. And > you don't get that with GML where there are similar checks ? > > Even Hi, I had a new look on the data and prepared a dataset for testing http://latuviitta.org/downloads/big_polygon_jml.zip The issue happens when GDAL reads JML file that is written by OpenJUMP. There is no errors if I convert the data into JML format with ogr2ogr. Main difference between those files is that GDAL writes the polygon geometry as one line but OpenJUMP is writing it formatted with line breaks and lots of white space 193588.34496920794,7005684.6655854415 193632.06812505925,7005834.808810625 193608.4497544446,7005874.299165146 -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Maximum geometry size for JML driver
Even Rouault spatialys.com> writes: > I downloaded it and don't see any issue. But it looks like it is the one > written by GDAL Oops, well, it is good to have reference data :) This is from OpenJUMP http://latuviitta.org/downloads/KKK.zip -Jukka- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Maximum geometry size for JML driver
Hi, I couldn't convert a dataset into JML format but got a message: "Too much data inside one element. File probably corrupted". Message seems to come from line 486 in https://trac.osgeo.org/gdal/browser/trunk/gdal/ogr/ ogrsf_frmts/jml/ogrjmllayer.cpp. My geometry is indeed quite big multipolygon with 185690 vertices and 9998 holes but it is a valid one and I can convert it into other formats with GDAL if I start from shapefile. I wonder what is the maximum amount of data inside an element and if the limit could be rised with some option. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motions: Promote 1.11.4 RC2 and 2.0.2 RC4 for release
Even Rouault spatialys.com> writes: > > Hi, > > Motion 1: GDAL/OGR 1.11.4 RC2 is promoted to be the official 1.11.4 final > release. > > Motion 2: GDAL/OGR 2.0.2 RC4 is promoted to be the official 2.0.2 final release. > > -- > > My votes : > Motion 1: + 1 > Motion 2: + 1 My votes: motion 1: +1 motion 2: +1 -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL 2.0.2 and 1.11.4: RC1 end of next week ?
Even Rouault spatialys.com> writes: > > Hi, > > What about preparing RC1s for both branches for end of next week ? +1 -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GeoPDF vs GeoSpatial PDF
Gane R gmail.com> writes: > > I have been browsing on the internet for finding the difference > between GeoPDF and Geospatial PDF. It seems that the terms geopdf and > geospatial are interchangeable used. Is the both geopdf and geospatial > are same, if so the PDF driver in gdal will handle geopdf and > geospatial PDF. > > Suggestions and references are appreciated. GeoPDF is a registered trademark of TerraGo technologies http://www.terragotech.com/Legal Geospatial PDF means largely any PDF that is georeferenced and GeoPDF is one variety of geospatial PDF. It is storing georeferencing data into PDF according to "OGC GeoPDF Encoding Best Practice Version 2.2" http://portal.opengeospatial.org/files/?artifact_id=40537. GDAL can also use the OGC best practice way for geo encoding but the result is not GeoPDF files because GeoPDF is (tm). Also, recent TerraGo programs like TerraGo toolbar do not read the georeferencing from GeoPDF-alike geospatial PDF files created by GDAL because they recognize if PDF has been written with some genuine licensed TerraGo product and is therefore a real GeoPDF. Another common way for geo encoding in PDF is "Adobe Supplement to ISO 32000" http://www.adobe.com/devnet/acrobat/pdfs/adobe_supplement_iso32000.pdf. Geospatial PDF is not (tm) and if someone creates a new way for geo encoding PDF the result can be called as geospatial PDF as well. In conlusion, all georeferenced PDF files are geospatial ones while only those created with software from TerraGo are GeoPDF(tm). -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Remapping nodata
Brad Hards frogmouth.net> writes: > > On Thu, 7 Jan 2016 11:09:10 AM Even Rouault wrote: > > gdal_translate -of VRT -a_nodata will not remap values, but just change the > > declared nodata value. > That is in the docs, but was still a little unexpected > > I did the gdalwarp solution, but as the source data gets larger, then the > resource cost of duplicating all the data goes up. Have you already tried gdal_calc http://www.gdal.org/gdal_calc.html? Option --NoDataValue=NODATAVALUE looks promising. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] OpenJPEG
Aaron Boxer gmail.com> writes: > This feature would be quite involved: one would have to gather all of the layers for > > all of the code blocks in all of the precincts overlapping that sub-tile,plus the immediately surrounding precincts, run the inverse entropy coder to get the wavelet coefficients, and then do an inverse wavelet transform,with this incomplete set of coefficients. > I do not claim that I understand GIS but I have a feeling that precincts are designed for a fast ROI access. From http://www2.engr.arizona.edu/~bilgin/publications/SPIE2004_2.pdf "A precinct is a collection of code-blocks representing some finite spatial extent at some resolution." Probably gathering the surrounding precincts is unnecessary. Author of Kakadu seems to dislike tiles and it is no wonder that with Kakadu precincts perform well even with archived documents http://www.digitizationguidelines.gov/still-image/documents/Martin.pdf. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Bad design in -clipsrs?
Hi, I wonder if this gis.stackexchange question http://gis.stackexchange.com/questions/167584/clipping-vs-intersecting could indicate that GDAL is doing clipping in a sub-optimal way, perhaps without utilizing spatial index or something like that. ArcGIS and OpenJUMP are claimed to clip linestrings 100 times faster than GDAL. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Question about ES SQL dialect
Hi, I am reading the ElasticSearch manual page http://www.gdal.org/drv_elasticsearch.html and I wonder what does this mean for an end user of ogrinfo and ogr2ogr "If specifying "ES" as the dialect of ExecuteSQL(), a JSon string with a serialized Elastic Search filter can be passed" Are ogrinfo and ogr2ogr analyzing automatically without any user input what is coming after "-where" or "-sql" and if it is json then it will be passed on? Should ElasticSearch be included in the Non-OGR SQL section of http://www.gdal.org/ogr_sql.html? -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Question about ES SQL dialect
Jukka Rahkonen maanmittauslaitos.fi> writes:
>
> Hi,
>
> I am reading the ElasticSearch manual page
> http://www.gdal.org/drv_elasticsearch.html and I wonder what does this mean
> for an end user of ogrinfo and ogr2ogr
>
> "If specifying "ES" as the dialect of ExecuteSQL(), a JSon string with a
> serialized Elastic Search filter can be passed"
>
> Are ogrinfo and ogr2ogr analyzing automatically without any user input what
> is coming after "-where" or "-sql" and if it is json then it will be
passed on?
>
> Should ElasticSearch be included in the Non-OGR SQL section of
> http://www.gdal.org/ogr_sql.html?
I have learned that users should know about the existence of the ES SQL
dialect if they want to use ES filters inside GDAL VRT data source. This VTR
works fine for me, notice the use of
ES:http://localhost:9200 allcountries
{
"query": {
"geo_shape": {
"geometry": {
"shape": {
"type": "envelope",
"coordinates": [[14, 52],[14.1, 52.2]]
}
}
}
}
}
-Jukka Rahkonen-
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] The "Magic" kernel
Graeme B. Bell nibio.no> writes:
>
> http://johncostella.webs.com/magic/
>
> I came across this article recently. Is this available as a resampling
kernel in GDAL? It looks very
> interesting.
Unfortunately I do not understand the mathematics of the {1/4, 3/4, 3/4,
1/4} kernel but if there is a way to turn this "magic" kernel into odd
kernel (odd as an opposite to even) you can use GDAL VRT.
http://cbloomrants.blogspot.fi/2011/03/03-24-11-image-filters-and-gradients.html
perhaps suggests that it is possible. GDAL KernelFilteredSource accepts only
odd filters.
I copy here an example about how to make GDAL to support the 5x5 unsharp
kernel https://en.wikipedia.org/wiki/Kernel_%28image_processing%29
Green
unsharp_filter_test.tif
2
5
1 4 6 4 1 4 16 24 16 4 6 24 -476 24 6 4 16 24 16 4 1 4 6 4
1
VRT works fine in QGIS and I can't notice any speed difference with
unfiltered image.
-Jukka Rahkonen-
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] How connect to a remote oracle with spatial
Andrea Peri gmail.com> writes: > > Hi, > I'm trying to test using gdal the access to an oracle dbms. > > To do this I use the ogrinfo and try this sintax but without success. > > ogrinfo OCI:username:password "(DESCRIPTION = (ADDRESS_LIST = (ADDRESS > = (PROTOCOL = TCP)(HOST = )(PORT = port>)))(CONNECT_DATA = (SID =))):." > > The server return > > ERROR 1: ORA-01005: null password given; logon denied > in > Don'n you have a record for your connection in the tnsnames.ora http://orafaq.com/wiki/Tnsnames.ora? If you have, use @SERVICE_NAME with ogrinfo Read also carefully the manual page http://www.gdal.org/drv_oci.html You wrote OCI:username:password but it should be OCI:username/password@database_instance:table,table As documented "ogrinfo OCI:username/password@database_instance" is enough but at least in our environment it can take several minutes to read the metadata from Oracle if table list is not given for limiting the search. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] How to find image footprints instead of envelopes?
Thomas Juntunen umn.edu> writes: > > > > Jukka, > > Have a look at Dan Stahlke's code he wrote when at GINA, I think gdal_trace_ooutline will do what you want:https://github.com/gina-alaska/dans-gdal-scripts > > Thomas Thanks Thomas, By looking at the number of different options and comments in the code this tool is very feature rich and obviously used for real production. The license seems to be BSD http://www.freebsd.org/copyright/license.html. I wonder if this tool could be reviewed and possibly added to GDAL utilities. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] The new @filename syntax and UTF-8 with BOM
Hi,
While testing the new ogr2ogr and ogrinfo option that was introduced in
https://trac.osgeo.org/gdal/changeset/30859 for reading contents for the
-where and -sql parameters from a file by using the @filename syntax I
noticed that system fails if the option file is saved with the Byte order
mark (BOM)
ERROR 1: SQL Expression Parsing Error: syntax error, unexpected end of
string. Occured around :
´╗┐{"query":
If I save the option file as UTF-8 without BOM then the file is read
correctly. Could GDAL be made to clarify the BOM if it exists, or should we
document that BOM is banned?
And now I understand why some of my mapfiles which I had to convert into
UTF-8 for Mapserver v. 7.0 did not work - the same BOM issue there.
-Jukka Rahkonen-
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] How to find image footprints instead of envelopes?
Hi, This question appears every now and then in the gis.stackexchange and I have been wondering about it by myself as well: How to generate a footprint polygon of the real image data area so that the possible nodata areas would not be included? I have been thinking that I could convert the original image into a new image with alpha channel or a one-bit image with nodata=0 and yesdata=1 and then polygonize the alpha band or the 1-bit image with gdal_polygonize.py. I guess that it would work but it feels a bit complicated. Is there any more direct way for doing this task with GDAL? I bet that at least someone has written a python script for it because the need is so obvious. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdal dll depedencies
Gane R gmail.com> writes: > > > I have build gdal from source of the lastet stable release gdal-2.0.1. Does all the drivers code go within gdal200.dll or any dependency exists ? I would use Dependency walker for checking that. You will find loads of dependencies. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL precision for Geometry object
Even Rouault spatialys.com> writes: > Hum I thought that WKT didn't allow scientific notation for coordinates, but > actually checking at http://portal.opengeospatial.org/files/?artifact_id=25355 > (SFA 1.2.1), page 52, it seems legal. So perhaps this could be changed. A quick test with OpenJUMP proofs that JTS can handle WKT like "POINT (1.01E1 2.01E1)". -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] decoding consistency between JPEG2000 drivers
Even Rouault spatialys.com> writes: > > Le vendredi 09 octobre 2015 20:26:34, Pierre Soille a écrit : > > Dear GDLALers, > > > > recently we tested the following 3 JPEG2000 drivers: JP2ECW, JPEG2000, > > and JP2OpenJPEG. A jp2 file was opened by all three drivers and we > > tested whether the decoded image were equal. To our suprise they are > > not: theJPEG2000 and JP2OpenJPEG lead to the same decoded image but they > > differ from the one obtained with JP2ECW. Is this a bug in the > > implementation of the JP2ECW driver or is there any rationale explanation? > > Pierre, > > I don't think the differences come from the GDAL drivers, but rather from > differences/bugs/features of the underlying libraries. Regarding JP2ECW, I > recall to have observed differences depending if you read component per > component or all components together. The version of the JP2 ECW SDK might > also have some influence. Hi, Were the original JPEG2000 files lossy or lossless? Getting slightly different results from lossy files does not feel critical but lossless conversion should naturally be lossless. It looks like I have seen an issue with ECWJP2 driver (SDK 3.x) a few years ago https://lists.osgeo.org/pipermail/gdal-dev/2009-January/019588.html I suppose that with the SDK v. 3.x the irreversible 9/7 trasformation was used also for reversible compression and/or decompression instead of the 5/3 transformation. I am not sure if the bug was ever corrected for SDK 3.x. Please make a test and report the results. If the bug is still there I suppose that it will never be fixed but at least we could document it because SDK 3.x is still used due to its more allowing license. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Add Kurt Schwehr to GDAL PSC
Even Rouault spatialys.com> writes: > > Hi, > > I propose to add Kurt Schwehr to the GDAL project steering committee. +1 -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Deviation with gdalwarp
Pedro Venâncio gmail.com> writes: > I leave my tests data so you can see the shift that I'm talking about:https://cld.pt/dl/download/2af4cb16-319f-4b43-988a-a529a9dc9806/Testes.zip Could you make a new zip with some other program or settings? This one gets blocked at least by Firefox as potential malware. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] How to merge tile trees
Ari Jolma gmail.com> writes: > > Dash, > > I have only a limited experience with tiles and gdal2tiles, so I'm not > sure the correctness of this but anyway. I'd also like to see if I have > understood correctly, so please anybody correct if I'm wrong. > > The tiles are in a two-level directory tree, where the top level has the > zoom level and the one below that has a number, which I assume is some > kind of global location reference. Within that there are the tiles, > which have a name, which, I assume, are some kind of global location > reference. For example I have this: I assume that your assumption of global location reference is correct when either "mercator" or "geodetic" profile is used. When profile is "raster" then the tile grid is based on the extents of the source data and merging directories from different rasters will not work. I fear that the result will be bad also with the global grids because the border tiles tend to contain partially nodata and as a result there will be more or less wide stripes of missing data at each zoom level at the outer borders of the added data. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motions: Promote 1.11.3 RC2 and 2.0.1 RC1 for release
Even Rouault spatialys.com> writes: > > Hi, > > Saving a few bits, 2 motions in one email: > > Motion 1: GDAL/OGR 1.11.3 RC2 is promoted to be the official 1.11.3 final > release. > > Motion 2: GDAL/OGR 2.0.1 RC1 is promoted to be the official 2.0.1 final release. > > -- > > My votes : > Motion 1: + 1 > Motion 2: + 1 +1 +1 -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Question about ogr2ogr and geojson url
Maxime Demers gmail.com> writes: > However, I have Failure Unable to open datasource with drivers... when trying to convert the geojson to shapefile from the url. > > ogr2ogr output.shp http://localhost:3000/711/points.geojson > > Can ogr2ogr convert dynamic geojson like I am trying to do, or it has to be a static geojson file? Hi, This works for me with GDAL 2.0, gisinternals Windows build: ogrinfo -ro -al "http://www.yournavigation.org/api/1.0/ gosmore.php?format=geojson=52.215676=5.963946& tlat=52.2573=6.1799=motorcar=1=mapnik" Result: using driver `GeoJSON' successful. Layer name: OGRGeoJSON Geometry: Line String Feature Count: 1 Extent: (5.963552, 52.196300) - (6.187562, 52.257125) Layer SRS WKT: GEOGCS["WGS 84", DATUM["WGS_1984", SPHEROID["WGS 84",6378137,298.257223563, AUTHORITY["EPSG","7030"]], TOWGS84[0,0,0,0,0,0,0], AUTHORITY["EPSG","6326"]], PRIMEM["Greenwich",0, AUTHORITY["EPSG","8901"]], UNIT["degree",0.0174532925199433, AUTHORITY["EPSG","9108"]], AUTHORITY["EPSG","4326"]] OGRFeature(OGRGeoJSON):0 LINESTRING (5.963585 52.21595,5.963585 52.21595,5.963563... -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL error from Mapserver 7.0
Even Rouault spatialys.com> writes:
> The crash is indeed linked to the fact that a wrong table name was passed.
And
> to reach that point the table name was of the form
> "table_name(geom_column_name)", right ?
>
> Fixed by https://trac.osgeo.org/gdal/ticket/6103
>
> As far as the why there's this one character offset, the fundamental cause
for
> the issue, I don't know without having a way to reproduce.
Hi,
I got a hint that it might originate from the SQLite driver as well but we
have not yet understood the code well enough:
size_t nFromPos = osSQLBase.ifind(" from ");
if (nFromPos == std::string::npos)
{
return std::pair((OGRLayer*)NULL, (IOGRSQLiteGetSpatialWhere*)NULL);
}
char chQuote = osSQLBase[nFromPos + 6];
int bInQuotes = (chQuote == '\'' || chQuote == '"' );
CPLString osBaseLayerName;
for( i = nFromPos + 6 + (bInQuotes ? 1 : 0);
i < osSQLBase.size(); i++ )
{
if (osSQLBase[i] == chQuote && i + 1 < osSQLBase.size() &&
osSQLBase[i + 1] == chQuote )
{
osBaseLayerName += osSQLBase[i];
i++;
}
else if (osSQLBase[i] == chQuote && bInQuotes)
{
i++;
break;
}
else if (osSQLBase[i] == ' ' && !bInQuotes)
break;
else
osBaseLayerName += osSQLBase[i];
}
-Jukka-
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL error from Mapserver 7.0
Even Rouault spatialys.com> writes: > As a workaround rewrite your SQL statement to quote the table identifier > > SELECT FROM "uusimmat_kuvat" > or > SELECT FROM 'uusimmat_kuvat' Thanks, it is good to show the workaround on the mailing list because it will take some time before we have 1.11.3 and 2.0.1 and users and distros have upgraded. -Jukka- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] GDAL error from Mapserver 7.0
Hi, We tried to update Mapserver from 7.0b1 into 7.0.0 and GDAL version was rised from 1.11.2 into 2.0.0. However, Spatialite tileindex layer stopped working. The error that comes from Mapserver is Program terminated with signal 11, Segmentation fault. #0 0x7efd01639b8e in OGRSQLiteTableLayer::Initialize (this=0x26013a0, pszTableName=0x24b30a0 "usimmat_kuvat", bIsVirtualShapeIn=, bDeferredCreation=) at ogrsqlitetablelayer.cpp:200 200 if( poFeatureDefn->GetGeomFieldCount() == 0 ) This part looks odd is pszTableName=0x24b30a0 "usimmat_kuvat". The table name in the mapfile and in Spatialite is actually "uusimmat_kuvat" Any idea what happens and where to search the reason for the error? -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] projection error
Hema Yeedunuri amigooptima.in> writes: > hi all, > i have a geotiff file .i have wrapper classes for gdal for reading and writing.gdal version is 1.11 and proj is 4.2 .whe i try to load a file it is giving following error.i am using ubuntu 12.04. > ERROR 1: Only OGC WKT Projections supported for writing to GeoTIFF. I fear that with that information nobody can solve your issue. The error suggests that you are trying to write into GeoTIFF something that is not OGC WKT Projection. You must tell us what you try to write into GeoTIFF, even better if you attach the failing code as well. You say that you try to load a file and the error says that you try to write something invalid into a file so perhaps your code does not do what you believe it does. For self-help I believe this is useful http://www.gdal.org/osr_tutorial.html and probably this also http://stackoverflow.com/questions/13158795/create-a-geotiff-from-an-existing-bitmap-in-c-sharp-with-gdal. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Gdaltransform hangs sometimes after being idle
Rahkonen Jukka (MML maanmittauslaitos.fi> writes: > > Hi, > > I can reproduce now. GDAL is 64-bit 2.1-dev from http://download.gisinternals.com/sdk/downloads/release-1600-x64-gdal-mapserver.zip Sorry, after further tests the problem with closing the program still happens only occasionally. Quite often I can see a "R6016 not enough space for thread data". It may something similar than in this thread: http://stackoverflow.com/questions/21127460/resolving-error-r6016-not-enough-space-for-thread-data Conclusions from that thread: "This turned out to be caused by calling CreateThread rather than _beginthread." "You have to call TlsAlloc in DllMain if the Windows version is Vista or higher." I think I will stop my investigations because this in not at all a critical issue for me. -Jukka- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] tiled vector map
Ahmet Temiz gmail.com> writes: > > > hello > > Is it possible to create tiled vector map with ogr ? It depends on what you mean with tiled vector maps. Do you mean for example something from this list http://wiki.openstreetmap.org/wiki/Vector_tiles or do you plan to develop your own system? -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Gdaltransform hangs sometimes after being idle
Hi, If I run gdaltransform on Windows and keep it idle for some time the whole command window freezes sometimes so that it does not accept any input, including Ctrl-C for closing the program. I have known the behavior for long and just closed the process from task manager. However, now I saw a new message on my screen which I have not noticed before. CPLMutexHolder: Failed to acquire mutex! Unfortunately I can't reprodoce the freeze in a reliable way. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Gdaltransform hangs sometimes after being idle
Even Rouault spatialys.com> writes: > > Le samedi 05 septembre 2015 17:39:52, Jukka Rahkonen a écrit : > > Hi, > > > > If I run gdaltransform on Windows and keep it idle for some time the whole > > command window freezes sometimes so that it does not accept any input, > > including Ctrl-C for closing the program. I have known the behavior for > > long and just closed the process from task manager. However, now I saw a > > new message on my screen which I have not noticed before. > > > > CPLMutexHolder: Failed to acquire mutex! > > > > Unfortunately I can't reprodoce the freeze in a reliable way. > > Jukka, > > This sounds rather strange. Most mutex locking attempts in GDAL have a timeout > of 1000 seconds, so that might explain the "after some time". However I fail > to see how waiting for input and mutex relate together. Or there would be a > mutex that wouldn't be released. What is your gdaltransform command line ? Actually I have the freeze on my computer right now. I did this: gdaltransform -s_srs epsg:4326 -t_srs epsg:3067 30 65 641428.429705435 7211811.30748109 0 31 70 652590.036387019 7770880.82231984 0 Then I tried to close the program with Ctrl-C but it did not close. Now it does not take any input at all. It may well be that my issue is exactly that I can't close gdaltransform with Ctrl-C after idle time and perhaps I have seen the same with cs2cs. In an earlier test I got this print on my screen, I don't know if it is related or not: HDF5-DIAG: Error detected in HDF5 (1.8.14) thread 0: #000: ..\..\src\H5I.c line 1138 in H5Iget_type(): library initialization faile d major: Function entry/exit minor: Unable to initialize object #001: ..\..\src\H5.c line 183 in H5_init_library(): unable to initialize prope rty list interface major: Function entry/exit minor: Unable to initialize object #002: ..\..\src\H5Pint.c line 405 in H5P_init(): interface initialization fail ed major: Function entry/exit minor: Unable to initialize object #003: ..\..\src\H5Pint.c line 468 in H5P_init_interface(): can't register prop erties major: Property lists minor: Unable to register new atom #004: ..\..\src\H5Pfapl.c line 241 in H5P_facc_reg_prop(): can't insert proper ty into class major: Property lists minor: Unable to insert object #005: ..\..\src\H5Pint.c line 2002 in H5P_register_real(): Can't create proper ty major: Property lists minor: Unable to create file #006: ..\..\src\H5Pint.c line 1072 in H5P_create_prop(): memory allocation fai led major: Resource unavailable minor: No space available for allocation #007: ..\..\src\H5FD.c line 386 in H5FD_register(): memory allocation failed f or file driver class struct major: Resource unavailable minor: No space available for allocation FATAL: CPLGetTLSList() failed to allocate TLS list! -Jukka- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Store also native geometry into Elastic Search?
Hi, What if somebody would like to put and deliver some official spatial data (cadastral data) which are not in EPSG:4326 with Elastic Search? Could it be possible to translate the geometries into EPSG:4326 and store and index them as geo_shape, but also keep the native geometries and save them into another field? Perhaps json does not like to have many geometry fields but how about saving the native geometry as WKT? Indexing WKT field feels stupid but maybe ES could be mapped to skip it. Reasoning is that conversion from native to EPSG:4326 and back to native is not necessary accurate and coordinates may change a bit. Am I even right that the conversion into EPSG:4326 is necessary for using the geo_shape query? -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] SRS of the Elastic Search geometries?
Even Rouault spatialys.com> writes: > > Hi Jukka, > > but I can still save for example > > EPSG:3067 geometries without transforming them into EPSG:4326. > > On-the-fly reprojection should occur normally (provided that your source layer > has explicit SRS) Probably that's it, the explicit SRS. I started with data that have native SRS epsg:3067 and OpenJUMP JML format which has no means for holding SRS. Conversion into ES gives always an empty layer, just the schema gets inserted but no geometries, even is I use -s_srs and -t_srs. Next trial was to convert JML into GML without assigning SRS. GML has an undefined SRS and conversion without -s_srs and -t_srs leads to a situation where metadata sayes that ES is using epsg:4326 but the features are in epsg:3067. With proper -s_srs and -t_srs the result is good. If I convert JML into GML and assign SRS with -a_srs epsg:3067 the result is the same as above. Each GML feature has SRS defined as but perhaps it is not explicit because conversion into ES gives correct result only when -s_srs and -t_srs are defined. So, two problems: - No way at all to use Jump JML as input format - With GML parameters -s_srs and -t_srs must be defined even if each GML feature has srsName and all features in the GML file have same srsName. A warning like "No explicit SRS found, use -s_srs and -t_srs" might be good to have. I know very little about Elastic Seaach, just started experiments a week ago. I have concluded that what is layer for GDAL is "index", and what is feature, is "document", and that documents are somehow saved as-is and clever indexes are built on top of them. Therefore I was thinking that perhaps everything is OK on the ES side even if the documents come out from it with epsg:3067 geometries. -Jukka- -Jukka- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] SRS of the Elastic Search geometries?
Hi, Are the geometries which are stored into Elastic Search supposed to be in EPSG:4326? Now I can see that the driver is writing EPSG:4326 definitions into the metadata of the ES index but I can still save for example EPSG:3067 geometries without transforming them into EPSG:4326. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] CSV driver does not understand allCountries.txt
Hi, I have understood that CSV driver should automatically recognize the allCountries.txt file from geonames.org. However, my GDAL 2.0 on Windows does not find any fields from the file. What is the expected output of ogrinfo -al -so -nocount -noextent allCountries.txt For me it only Geometry: None Layer SRS WKT: (unknown) [the first line of the allCountries.txt file] -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] CSV driver does not understand allCountries.txt
Jukka Rahkonen jukka.rahkonen at maanmittauslaitos.fi writes: By closer look it is not exactly that way. However, I guess that the structure of data is changed. http://download.geonames.org/export/dump/readme.txt is listing fields name, asciiname, alternatenames but the data sample that we have in autotest/ogr/data/allCountries.txt?rev=27748 seems to have just one name field. The schema in trunk/gdal/ogr/ogrsf_frmts/csv/ogrcsvlayer.cpp?rev=27748 looks correct under asGeonamesFieldDesc[] = but what probably happens is that the code truncates alternatenames when it meets comma that is separating the list entries. Here is an example about what I have in alternatenames Pic de Font Blanca,Pic du Port -Jukka- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] CSV driver does not understand allCountries.txt
Jukka Rahkonen jukka.rahkonen at maanmittauslaitos.fi writes: Hi, I have understood that CSV driver should automatically recognize the allCountries.txt file from geonames.org. However, my GDAL 2.0 on Windows does not find any fields from the file. What is the expected output of ogrinfo -al -so -nocount -noextent allCountries.txt For me it only Geometry: None Layer SRS WKT: (unknown) [the first line of the allCountries.txt file] By closer look it is not exactly that way. However, I guess that the structure of data is changed. http://download.geonames.org/export/dump/readme.txt is listing fields name, asciiname, alternatenames but the data sample that we have in autotest/ogr/data/allCountries.txt?rev=27748 seems to have just one name field. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] How to read ElasticSearch filters from file?
Hi, I was trying the new read capabilities of the ElasticSearch driver http://www.gdal.org/drv_elasticsearch.html and I found it extraordinary hard to use the json filters from the command line on Windows. It is hard also with curl so I saved the filters on disk and read them as -d @file.json and that worked well for me. I tried if I could re-use those proved filters with ogrinfo and ogr2ogr by using --optfile but with poor success. Could it be possible to add a new --config option or perhaps -oo open option ES_QUERY for reading the json query/filter from a file just like curl does with -d @file.json? The same file should work unmodified for both software. I think especially newlines which make the filters more readable and also most filter examples in the net are formatted with newlines. See the examples at https://www.elastic.co/guide/en/elasticsearch/guide/current/search-in-depth.html -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] How to read ElasticSearch filters from file?
Even Rouault even.rouault at spatialys.com writes: Hi Jukka, Ah, might be true. The Unix shell allows to paste things like: What about ogrinfo ES: the_layer -where at filter.json ? Iniitally, I though this could be a hack specific to the ES driver. But there's the same thing with the mongodb driver. So perhaps an extended behaviour of the -where options of ogrinfo / ogr2ogr that would do the file reading and transmit the expanded filter to the driver ? Could be usefull for -sql as well I guess. Hi, I can't invent anything better than -where at filter.json and at is also used for the same purpose by curl and Oracle PL/SQL so we could call it as a de facto standard. Which one should win if -spat and -where @... are both feeding a spatial filter? Should it be either-or, or both as a combined filter with AND in between? -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Question
Giorgio Ghiggini gghiggini at gec-it.com writes: Hello, I am trying to use GDAL ogr2ogr.exe but I am having problems with osmconf.ini file configuration. I tried using different binaries for Windows (QGIS, Gisinternals, OSGeo4W and MapServer) but I am not able to get all tags from a PBF or OSM file. Probably I am not able to configure properly the ini file (here attached), but all changes I do, have no impact on the result. Here is the command line I use: ogr2ogr -f ESRI Shapefile -skipfailures -sql select * from points where other_tags LIKE '%peak%' F:\GEC\Sources\OSM\Italy F:\GEC\Sources\OSM\italy-latest.osm.pbf With this configuration I would like to export the “ele” attribute for “natural=peak”, but I am not able to get it in my shapefile. Any suggestion is very appreciated. Hi, Check first the effect of your osmconf.ini with ogrinfo: ogrinfo hamburg-latest.osm.pbf points -so With your osmconf.ini I can see attributes: osm_id: String (0.0) name: String (0.0) barrier: String (0.0) highway: String (0.0) ref: String (0.0) address: String (0.0) is_in: String (0.0) natural: String (0.0) place: String (0.0) man_made: String (0.0) ele: String (0.0) all_tags: String (0.0) You have all_tags=yes in osmconf.ini which means at the same that you do not have other_tags. Now the following command works for me: ogrinfo hamburg-latest.osm.pbf -sql select * from points where all_tags like '%collection%' -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdal2tile
Even Rouault even.rouault at spatialys.com writes: 2 possible workarounds : - download https://svn.osgeo.org/gdal/trunk/gdal/data/cubewerx_extra.wkt and copy it to /usr/share/gdal/1.10 so as to get 900913 - edit /usr/bin/gdal2tiles.py and replace all occurences of 900913 by 3857 Hi, Wouldn't it be time to bury 900913 permenently? There is also an open ticket about that https://trac.osgeo.org/gdal/ticket/5622 -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] 2.0.1 (and 1.11.3) release schedule ?
Even Rouault even.rouault at spatialys.com writes: Hi, I was wondering if we couldn't prepare RCs of 2.0.1 and 1.11.3 for the week of September 14th. That would be 3 months after 2.0.0 release. There are ~ 30 tickets closed in both branches. Nothing dramatically critical I can think of, but going beyond the .0.0 of 2.0.0 will probably make it more psychologically attractive for wider adoption. Does that sound OK ? Anybody interested in tackling that ? Otherwise I guess I have some idea for a volunteer... +1 for making releases. I doubt you get too many volunteers, for our team even casting votes is sometimes too heavy a task. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] JasPer vs OpenJPEG performance
Brad Hards bradh at frogmouth.net writes: On Fri, 7 Aug 2015 11:17:56 AM Jukka Rahkonen wrote: NITF requires either that the tile size must not be bigger that 1024x1024, or that the whole file is written as one single tile. I believe you have such single-tile NITF file. I don't believe this is true (at least in NITF 2.1 - MIL-STD-2500C) for two reasons: 1. Tiling is mandatory above 8192 x 8192 (See Table A-10 Complexity Level 7 or higher) 2. Tiles are allowed to be up to 2048 x 2048 (Complexity level 3) or 8192 x 8192 (Complexity level 5 or higher). Hi Brad, I read the NITF 2.1 - MIL-STD-2500C http://www.gwg.nga.mil/ntb/baseline/docs/2500c/2500C.pdf in the same way than you do. However, I wrote my comments after reading another (older) document: NATIONAL IMAGERY TRANSMISSION FORMAT (NITF) VERSION 2.1 COMMERCIAL DATASET REQUIREMENTS DOCUMENT (NCDRD) http://www.gwg.nga.mil/ntb/baseline/docs/stdi0006/NCDRD_18February2010.pdf And especially part 2.3.2 JPEG 2000 Image Geometry Segmentation Commercial datasets shall be organized in JPEG 2000 tiles as described in BPJ2K01.00 Section 8. I believe that the referred document is this: http://www.gwg.nga.mil/ntb/baseline/docs/bpj2k01/ISOJ2K_profile.pdf Appendix C JPEG 2000 Commercial Profiles (ISO/IEC IS 15444-1 Annex A.10) , Table C-1. Codestream Restrictions: Profile-0: Tiles of a dimension 128x128: YTsiz=XTsiz=128 or one tile for the whole image: YTsiz+YTOsiz=Ysiz XTsiz+XTOsiz=Xsiz Profile-1 XTsiz/min(XRsiz, YRsiz)=1024 XTsiz=YTsiz or one tile for the whole image: YTsiz+YTOsiz=Ysiz XTsiz+XTOsiz=Xsiz It may be that tiling is mandatory for images bigger than 8192 x 8192 because of the baseline standard. On the other hand is seems that commercial vendors are not allowed to use multiple tiles if they are larger than 1024 x 1024. I did not dig too deep into the black hole between 1024 x 1024 and 8192 x 8192. BTW. In the Inspire guidelines for orthoimagery the same one tile or max 1024 x 1024 tiles regulations in http://inspire.ec.europa.eu/documents/Data_Specifications/INSPIRE_DataSpecification_OI_v3.0.pdf: JPEG 2000 allows internal tiling within the codestream. Profile 1 of ISO 15444 - 1 already requires no tiling (i.e. the image = 1 tile) or tiling with tiles size [no] bigger than 1024x1024 pixels. There is no further requirement I have added [no] into the quotation. The Inspire text does not have the word which makes the the sentence to mean the opposite but it must be a typo. See comment 8 in https://trac.osgeo.org/gdal/ticket/5697. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] JasPer vs OpenJPEG performance
ewenger ewenger at ara.com writes: I'm building GDAL 2.0 with JPEG-2000 support for my current project and I was surprised about the performance differences I saw between JasPer and OpenJPEG. Using JasPer, gdal_translate is able to decompress a 465 MB NITF C8 file in 2.3 minutes (wall clock) even though JasPer runs single-threaded. OpenJPEG took 4.4 minutes (wall clock) and used 24.5 minutes in CPU time across the four threads that were spawned. Is there some trick to building OpenJPEG that I'm not following or has anyone tried to multithread JasPer? Hi, Could you point us any similar sample image for testing? Based on your timings both drivers are actually unusable for any real work with your images. OpenJPEG is usually rather fast and much better than JasPer but it can't handle any bigger images which are compressed into JPEG2000 as one tile. NITF requires either that the tile size must not be bigger that 1024x1024, or that the whole file is written as one single tile. I believe you have such single-tile NITF file. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] JasPer vs OpenJPEG performance
ewenger ewenger at ara.com writes: Jukka, Thank you for your response. I can't provide the image, but we're working with 8-band MSI from Worldview-2 so the images are larger than 1024x1024. Given your information, it sounds like compiler flags aren't going to help. Do you think I'll see better performance on these tiles using either the Kakadu or the ECW driver? Hi, The tiled image can be however large, tiling means only that the JPEG2000 codestream is internally split into max. 1024x1024 sized parts. But if your image is having only one tile I fear you are out of luck with OpenJPEG. If you know Kakadu then you probably has also kdu_view application available. File-Properties shows you all the details about the file. You should get more info also with these GDAL utilities https://trac.osgeo.org/gdal/wiki/UserDocs/JPEG2000Utils With Kakadu or ECW driver you will get an enormous boost. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Additon to r29598
Hi Even, By browsing what you have done with https://trac.osgeo.org/gdal/changeset/29598, should I understand that there is also a need for an additional edit in http://www.gdal.org/drv_elasticsearch.html, here: However, the driver is limited in the geometry it handles: even if polygons are provided as input, they are stored as geo point and the center of the polygon is used as value of the point. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Non-standard characters in GeoPackage table names
Even Rouault even.rouault at spatialys.com writes: Third and and perhaps best possibility might be to edit the Annex A Conformance / Abstract Test Suite (Normative) part of the GeoPackage standard to use quoted identifiers everywhere. Now the first test in the test suite that fails with test-table seems to be already the third one: A.1.1.1.1.3 File Contents Test Case ID: /base/core/container/data/file_contents Test Purpose: Verify that the Geopackage only contains specified contents Test Method: 1) For each gpkg_* table_name a) PRAGMA table_info(table_name) ... Should be written as PRAGMA table_info(table_name)... In the above, table_name is intended to be a variable / symbolic name. If the test was written PRAGMA table_info(table_name), it could potentially be confused with the table_name identifier. I guess this is the reason for this test suite to be qualified as Abstract, because it only gives the intent of the test, but the actual test suite has to be implemented in a programming language. Ok, I agree. However, I would recommend for everybody who is making GeoPackage software or running interoperability tests also to test if it is possible to create and use tables which are named so that using quotes in the SQL is necessary. I have a feeling that there is a high risk of non-interoperability in here. At least I am lazy and I do not usually write identifiers as quoted in my SQL queries. I would not be surprised if programmers are lazy too and there can already exist GeoPackage programs which do simply SELECT attribute FROM table; instead of SELECT attribute FROM table; even the latter syntax is necessary for example in case like SELECT attribute-with-dash FROM table-with-dash; -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Non-standard characters in GeoPackage table names
Hi, Have a look at this QGIS issue https://hub.qgis.org/issues/13140. Problem it that QGIS can't create tables with names like test-table into GeoPackage. I think that the reason is that SQLite requires double quotes around such name. This command works: create table test-t (id, value); while this one does not: create table test-t (id, value); GeoPackage standard does not seem to limit the table names. However, all the tests in the standard are using SQL without double quotes around the identifiers which means that tests would fail with tables having names like test-table. What to do? If I could I would edit the standard and tell which characters are allowed in table names and possibly the same with attribute names. Because that is not possible, should we consider to write such recommendation into GDAL documents? I think it would be a bad idea to make GDAL capable to create tables with whichever names at least without hearing the opinion of OGC GeoPackage group first. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Adopt FRC48: Geographical networks support
Dmitry Baryshnikov bishop.dev at gmail.com writes: I think it's time to vote for adopt the RFC 48 Geographical networks support and to merge the pull request to the GDAL sources trunk. According to https://trac.osgeo.org/gdal/wiki/rfc1_pmc I start the vote and my +1 for adopt. +1 -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] decimal rounding issue when re-projecting
Ramiro Marco Figuera r.marcofiguera at jacobs-university.de writes: Hi, I'm re-projecting (from stereographic to gnomonic) the PDS LOLA 20m/pix DTMS from the lunar south pole. Im using gdalwarp like this: 'gdalwarp -t_srs '+proj=gnom +lat_0=-90 +lat_ts=-90 +lon_0=0 +k=1 +x_0=0 +y_0=0 +a=1737400 +b=1737400 +units=m +no_defs' topo_stereo.tif topo_gnom.tif' . After that, I'm cropping the DTM to have a smaller region (200km by 200km) around the pole. Then, I just use gdal_translate to export it as XYZ since I need it in this format for my software and converting it to kilometers instead of meters using awk. As this is a gridded data, the resolution should remain the same (20m/pixel), however when I check the first entries of my xyz file the resolution is sometimes 21 m/pixel and sometimes 20 m/pixel, and this happens randomly. Any clue of what may cause this error? Has anyone faced the same issue? Hi, Gdalwarp does not try to keep resolution unchanged and I guess that the reason is to avoid extra resampling. That your output is so close to 20 m/pix is a coincident. Varying 20/21 m pixel size in xyz file may be due to rounding errors. Have you checked the pixel size of topo_gnom.tif with gdalinfo? I would try what happens when running gdalwarp with -tr 20 20 for forcing the output resolution to 20m/pix. You should be able to crop and create 20 m/pixel xyz file with one run by setting the resolution with -tr and selecting the format with -of and defining extents with -te http://www.gdal.org/gdalwarp.html -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Gdal_calc.py with more than 26 input files
Hi, Have a look at this gis.stackexchange question: http://gis.stackexchange.com/questions/149006/does-gdal-calc-only-support-26-input-raster-files-at-a-time So, what users can do if they have more than 26 input files? -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Transparency mask (alpha band) in ECW
Even Rouault even.rouault at spatialys.com writes: GDAL ECW driver does not have support for this. I wonder if it could be doable and if I should make a feature request. I also wonder if GDAL can decode ECW files which have transparency mask correctly. Jukka, I'm a bit confused by the above. If you look to the bottom of the page you mentio,n you'll see a gdalinfo report with an alpha band. And I've just tried with a test file of the autotest suite: gdalinfo ../gdrivers/data/stefan_full_rgba_ecwv3_meta.ecw This is a ECWv3 file. I don't have an example with ECWv2 and the appended mask, but I believe the driver should also likely be able to read/write this (but I haven't a ECWv2 image with alpha handy) Hi Even, I apologize, I do not use ECW myself nowadays but I was reading this gis.stackexchange question which deals actually with FME http://gis.stackexchange.com/questions/153490/how-to-convert-tif-to-ecw-with-fme-maintaining-a-certain-value?noredirect=1#comment225797_153490 Then I read our ECW manual page http://www.gdal.org/frmt_ecw.html which does not talk anything about nodata, alpha, transparency etc. I just thought that we can't handle nodata any better than FME but obviously we can. I do not have SDK license so I could not test ECW output myself. Is the ECW transparency band created automatically if user has Read/Write SDK = 4.0 and source data has either alpha channel or nodata set in GeoTIFF? ECW driver does not seem to have any creation option for that but perhaps it is not necessary. -Jukka- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Transparency mask (alpha band) in ECW
Hi, Nodata values with lossy compression like JPEG, ECW, or JPEG2000 do not really work. I noticed that newest ECW SDK versions (= 4) have support for using a transparency mask: http://blog.hexagongeospatial.com/help-ecw-speckled-edges/ Using the ECWJP2 SDK terminology, a transparency mask is implemented as an opacity band called AllOpacity. GDAL ECW driver does not have support for this. I wonder if it could be doable and if I should make a feature request. I also wonder if GDAL can decode ECW files which have transparency mask correctly. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Attempting to access an ArcGIS REST API through a WMS format minidriver
Passmore, James H. jpass at bgs.ac.uk writes: When I try on a BGS service it fails as below: ...:\gdalinfo https://map.bgs.ac.uk/arcgis/rest/services/UKSO/UKSO_BGS/MapServer? f=jsonpretty=true gdalinfo failed - unable to open 'https://map.bgs.ac.uk/arcgis/rest/services/UKSO/UKSO_BGS/MapServer? f=jsonpretty= true'. ... Is the reason that HTTPS is not supported here at all, or if not what might be wrong with the service/request/ configuration? By adding --debug on into the request I saw a message: HTTP: Fetch(https://map.bgs.ac.uk/arcgis/rest/services/UKSO/ UKSO_BGS/MapServer?f=jsonpretty=true) WMS: Did not get levels Another trial with browser showed some differences between http://server.arcgisonline.com/ArcGIS/rest/services/World_Imagery/MapServer?f=jsonpretty=true and https://map.bgs.ac.uk/arcgis/rest/services/UKSO/UKSO_BGS/MapServer? f=jsonpretty=true The first one sends elements like level: 0, resolution: 156543.03392800014, scale: 5.91657527591555E8 but the latter not. I suppose that missing levels is the reason for the failure. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Adopt RFC 26: GDAL Block Cache Improvements
Even Rouault even.rouault at spatialys.com writes: Hi, As no points have been raised on the RFC: Motion : I move to adopt RFC 26: GDAL Block Cache Improvements https://trac.osgeo.org/gdal/wiki/rfc26_blockcache Starting with my +1 +0 Unfortunately I Can't say anything about the implementation so 0 but avoiding out of memory errors with large images is for sure worth +. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Gdal_translate considers --config means -co
Hi, Spotted this from gis.stackexchange http://gis.stackexchange.com/questions/151153/is-gdal-translate-ignoring-the-cpl-tmpdir-switch I repeated the test on Windows with GDAL 2.0 and it seems indeed that using --config option in the beginning of gdal_translate command fails. Like it would be cut at -co and interpreted to mean something totally different. Moving --config to the end of the command leads to success. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
