Re: [gdal-dev] gdalwarp skews and rotates PDF rasters, when converting to GeoTIFF, when PDF raster are in Landscape orientation or (True north facing botton or right or left)
Le vendredi 17 avril 2015 14:43:43, Gane R a écrit : > I am using gdal 1.10.1 > > I have a set PDFs, I am converting them to GeoTIFF. > > I am using gdal with poppler for pdf driver. > > I have PDFs of places with orientation in Landscape, and north facing right > or left or bottom. > > When I apply a gdalwarp for these PDFs I get unexpected rotation at GeoTIFF > output. > > I read this link too > > http://lists.osgeo.org/pipermail/gdal-dev/2014-June/039438.html Now fixed in trunk, in the particular case provided by Gane, with OGC Best Practice encoding and rotation = 90. Other cases might require additional adjustments. > > > I need some guidance for this. Say some kind of work flow with gdal command > line tool will be of great help. > > Thanking you, > Gdal gurus. -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Masks vs nodata?
Sean, > > Not being able to unset nodata values for datasets is tripping up GDAL > users at work. I'm considering measures that require 1-bit internal masks > (we're primarily using GeoTIFF) instead of nodata values because, unlike > nodata, the masks can be "cleared" by setting them uniformly to True using > the GDAL API (GDALFillRaster() specifically). If there are external masks .msk, you'd better just deleting the file. That will save a bit some processing time for algorithms that deal with masks. > > Background: the GeoTIFF driver's SetNoDataValue() method doesn't let us > remove or set a null or empty nodata value or unset the bNoDataSet flag. A ClearNoDataValue() could be an interesting addition to the GDAL API indeed. I'm pretty sure there are tickets about that. > Passing a value outside the range of values in the dataset can be > problematic, especially for 8-bit data. Passing -inf, nan, or 256 to > SetNoDataValue() has the same effect on derived masks as passing 0. Looking at gcore/gdalnodatamaskband.cpp, it indeeds casts dfNoDataValue to GByte without checking. Should probably do better checking, although setting out-of-range nodata value is a bit in the unspecified behaviour area. > > I'm looking for expert advice on consequences of using masks instead of > nodata values. Are there features of GDAL that rely on nodata values and > don't respond to masks? I wouldn't be surprised that some algorithms there or there only work with the nodata concept and not with the more general concept of masks (GDALContour for example from a quick searching) > Are there adverse implications for > interoperability? In TIFF, I don't think one of nodata or nodata masks can be considered as more interoperable as the other. the GDAL_NODATA TIFF tag is a GDAL specific TIFF tag. If you use external masks (.msk), they are a GDAL specific thing. And if you use TIFF internal masks, they are quite an esoteric formulation of TIFF. > Would it be better to simply accept nodata values as > being part of the structure of datasets, like tiling and interleaving, and > immutable once set? Some drivers accept modifying geotransform or projection, so it is not really clear what users might want to change after a dataset has been created. But in your use case, it seems that the users do have use case for clearing an existing nodata value, so I'm not sure to follow your reasonning about what should be immutable. The easiest way to clear nodata currently is to use : gdal_translate -a_nodata none in.tif out.tif Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Masks vs nodata?
Hi all, Not being able to unset nodata values for datasets is tripping up GDAL users at work. I'm considering measures that require 1-bit internal masks (we're primarily using GeoTIFF) instead of nodata values because, unlike nodata, the masks can be "cleared" by setting them uniformly to True using the GDAL API (GDALFillRaster() specifically). Background: the GeoTIFF driver's SetNoDataValue() method doesn't let us remove or set a null or empty nodata value or unset the bNoDataSet flag. Passing a value outside the range of values in the dataset can be problematic, especially for 8-bit data. Passing -inf, nan, or 256 to SetNoDataValue() has the same effect on derived masks as passing 0. I'm looking for expert advice on consequences of using masks instead of nodata values. Are there features of GDAL that rely on nodata values and don't respond to masks? Are there adverse implications for interoperability? Would it be better to simply accept nodata values as being part of the structure of datasets, like tiling and interleaving, and immutable once set? Thanks, ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] building interface to org2org
Hello, On Monday, April 20, 2015 12:01:34 Błażej Doruch wrote: > ...but in QGIS, and also new version of FWtools 2.4.7 it's some kind of > mistake in transformation beetween EPSG:2175 and 2175 (about 40 meters > displacement) > that's why I must use older version - FWtools 1.3.5 . > And the second reason why I want to do it is that in QGIS as I know there > is no multiple file transformation option. FYI, It does with the processing tools. Y. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] building interface to org2org
Błażej Doruch gmail.com> writes: > > > org2gui looks nice, but there is no support for EPSG that I need.Blaze > I rather believe that there is some bug that cuts loads of supported projections from the drop-down menu. Try adding your projections directly into the Options box in ogr2ogr syntax, for example -s_srs epsg:4326 -t_srs epsg:2175 With those options ogr2gui wrote a shapefile for me with a .prj file PROJCS["Pulkovo_1942_58_Poland_zone_V",GEOGCS["GCS_Pulkovo 1942(58)",DATUM["D_Pulkovo_1942_Adj_1958",SPHEROID["Krasovsky_1940", 6378245,298.3]],PRIMEM["Greenwich",0],UNIT["Degree", 0.017453292519943295]],PROJECTION["Transverse_Mercator"], PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian", 18.958333],PARAMETER["scale_factor",0.83], PARAMETER["false_easting",237000],PARAMETER["false_northing", -470],UNIT["Meter",1]]. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] building interface to org2org
org2gui looks nice, but there is no support for EPSG that I need. Blaze 2015-04-20 12:57 GMT+02:00 Brad Hards : > On Mon, 20 Apr 2015 12:01:34 PM Błażej Doruch wrote: > > ...but in QGIS, and also new version of FWtools 2.4.7 it's some kind of > > mistake in transformation beetween EPSG:2175 and 2175 (about 40 meters > > displacement) > Maybe worth filing a bug report to get it fixed instead of working around > the > problem. > > Brad > -- Błażej Doruch blazej.dor...@gmail.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] building interface to org2org
On Mon, 20 Apr 2015 12:01:34 PM Błażej Doruch wrote: > ...but in QGIS, and also new version of FWtools 2.4.7 it's some kind of > mistake in transformation beetween EPSG:2175 and 2175 (about 40 meters > displacement) Maybe worth filing a bug report to get it fixed instead of working around the problem. Brad ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] building interface to org2org
Nick Ves gmail.com> writes: > > You can try ogr2gui. I haven't used it tho. Give it a spin and > afterwards if you want you can tell us if its any good. > > http://www.ogr2gui.ca/en/index.php Ogr2gui is excellent but a new build would be needed. Version 0.7 seems to be built 2014-06-12 on top of GDAL 1.11. I had to check the date by looking at the files inside the zip. Perhaps the date under the latest news title is updating automatically to current date? Starting to make frequent builds of ogr2ogr would give much value for the community and probably with a reasonable amount of work and time once the machinery is running. Any takers? -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] building interface to org2org
You can try ogr2gui. I haven't used it tho. Give it a spin and afterwards if you want you can tell us if its any good. http://www.ogr2gui.ca/en/index.php On Mon, Apr 20, 2015 at 1:01 PM, Błażej Doruch wrote: > ...but in QGIS, and also new version of FWtools 2.4.7 it's some kind of > mistake in transformation beetween EPSG:2175 and 2175 (about 40 meters > displacement) > that's why I must use older version - FWtools 1.3.5 . > And the second reason why I want to do it is that in QGIS as I know there is > no multiple file transformation option. > > Blaze > > 2015-04-20 11:06 GMT+02:00 Eloi : >> >> On 2015-04-20 10:20, Błażej Doruch wrote: >>> >>> Has anybody make program which implement org2org, >>> >>> I need to have such functionality: >>> -select file (files) to convert; >>> -select type of conversion (source and destination EPSG- only >>> 2175-2177 (both ways)); >>> -select type of file format; >>> -make conversion; >> >> >> QGIS. >> http://qgis.org >> >> -- >> Eloi Ribeiro >> Geoinformatic >> 51.9871, 5.6661 >> http://eloiribeiro.eu (home server, probably down o_O) >> ___ >> gdal-dev mailing list >> gdal-dev@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/gdal-dev > > > > > -- > Błażej Doruch > blazej.dor...@gmail.com > > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] building interface to org2org
...but in QGIS, and also new version of FWtools 2.4.7 it's some kind of mistake in transformation beetween EPSG:2175 and 2175 (about 40 meters displacement) that's why I must use older version - FWtools 1.3.5 . And the second reason why I want to do it is that in QGIS as I know there is no multiple file transformation option. Blaze 2015-04-20 11:06 GMT+02:00 Eloi : > On 2015-04-20 10:20, Błażej Doruch wrote: > >> Has anybody make program which implement org2org, >> >> I need to have such functionality: >> -select file (files) to convert; >> -select type of conversion (source and destination EPSG- only >> 2175-2177 (both ways)); >> -select type of file format; >> -make conversion; >> > > QGIS. > http://qgis.org > > -- > Eloi Ribeiro > Geoinformatic > 51.9871, 5.6661 > http://eloiribeiro.eu (home server, probably down o_O) > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Błażej Doruch blazej.dor...@gmail.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] building interface to org2org
On 2015-04-20 10:20, Błażej Doruch wrote: Has anybody make program which implement org2org, I need to have such functionality: -select file (files) to convert; -select type of conversion (source and destination EPSG- only 2175-2177 (both ways)); -select type of file format; -make conversion; QGIS. http://qgis.org -- Eloi Ribeiro Geoinformatic 51.9871, 5.6661 http://eloiribeiro.eu (home server, probably down o_O) ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] building interface to org2org
Has anybody make program which implement org2org, I need to have such functionality: -select file (files) to convert; -select type of conversion (source and destination EPSG- only 2175-2177 (both ways)); -select type of file format; -make conversion; I need to do it but I really don't know how. If somebody has such experience plese answer. Blaze. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] create GeospatialPDF using Python
On 17 April 2015 at 15:12, Even Rouault wrote: > > > I can open it. See below. If you tried different ./configure options between > builds, make sure to make clean before rebuilding, otherwise files might not > get recompiled > Ok, rebuild from scratch it works. Last question, I have GeospatialPDF with the right style for vector and I tried to join it with geotiff, the output has right geometries position but wrong color, could be this a bug? -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
