Re: [gdal-dev] OGR functionality to remove holes?
Hi, Yes, that is indeed what I meant. Sorry, couldn't explain it more clear. This forum post shows a screenshot of how GlobalMapper updates the polygons to remove the holes. http://www.fsdeveloper.com/forum/showpost.php?p=613313postcount=25 I have already implemented some logic that makes the seam to remove the holes, but that fails on complex polygons with many holes that I created with GDAL Polygonize. So that's why I was wondering if GDAL itself maybe has some functionality to get rid of the holes. But maybe I should more be thinking along the line of splitting the polygon into chunks, instead of trying to describe it as one polygon with those seams. Arno -- View this message in context: http://osgeo-org.1560.x6.nabble.com/OGR-functionality-to-remove-holes-tp5099099p5099175.html Sent from the GDAL - Dev mailing list archive at Nabble.com. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Reading CurveString and CurvePolygon Geometries from FGF Data
Even Rouault wrote Le vendredi 17 janvier 2014 17:08:38, Bob Cave a écrit : Hello, I am using the OGR Spatialite driver to read a database that has FGF geometries. Some of the geometries are CurvePolygons, which are not currently supported in OGRGeometryFactory::createFromFgfInternal() as of GDAL 1.10.1. Is support for FGF CurveString and CurvePolygon geometries currently in development? Not that I'm aware of. There's not yet support in OGR core for curve geometries, so that would be a preliminary step to implement support for the FGF curve geometries. This is something that could be part of the big changes for OGR 2.0 (http://trac.osgeo.org/gdal/wiki/GDAL20Changes). A few years ago I had started preliminary work in a sandbox but didn't pursue. Another annoying thing for implementation is that the link in http://trac.osgeo.org/fdo/wiki/FDORfc16 to the FGF binary spec seems to have disappeared. Do people actually use FDO SQLite databases ? Apparently, one of our customers uses an FDO SQLite database. I have seen that the OGR core does not currently support curve geometries, so these objects could not be handled that way. I was thinking that perhaps someone might be working on producing a polyline or polygon representation of an FGF curve object. I found the FGF Binary Specification here http://www.osgeo.org/files/fdo/docs/FDG_FDODevGuide/files/WSfacf1429558a55de8821c21057fbebc2b-789.htm . Thanks, Bob -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Reading-CurveString-and-CurvePolygon-Geometries-from-FGF-Data-tp5098667p5099296.html Sent from the GDAL - Dev mailing list archive at Nabble.com. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Question about gdaladdo and raster mosaicking
Ammar, You are using lossy JPEG compression. I'm guessing that the white lines are are actually pixels with values near but not equal to 255. So, they are not treated as nodata pixels. My suggestion is to use another format with lossless compression for the 21 images or use a mask band if you prefer. Let me know how it goes. -- Best regards, Chaitanya Kumar CH On 21-Jan-2014 5:31 pm, ammar8...@yahoo.com wrote: Hello Chaitanya, I was looking online for solutions to my problem and I cam across some of your posts so I thought you might help me with my problem. I have 10,000+ TIFF files that I want to merge into one big Image and serve using GeoServer. I merged every 500 images at a time creating using gdalbuildvrt and gdal_translate along with JPEG compression creating 21 TIFF files. I added overviews then to each of the new 21 files. When adding the images together, once directly as files using QGIS and another time as WMSs using GeoServer, I got white lines/gaps precisely at the border of ever 2 images. I thought the problem is with no data values but I decided to take another approach and merged all the 10,000 files into one huge image and this time I got one perfect image with no lines or gaps. I failed to create overviews for the big image because the process took days or gdaladdo running with no progress. I tested then on smaller images with and without overviews and the ones with no overview came perfect while the one with gdaladdo overviews came with the same problem of lines and gaps. The commands I m using are the following: gdalbuildvrt -srcnodata 255 -vrtnodata 255 -a_srs EPSG:27700 -input_file_list tiff_list.txt mosaic.vrt gdal_translate -of GTiff -co TILED=YES -co BIGTIFF=YES -co COMPRESS=JPEG -co JPEG_QUALITY=80 -co BLOCKXSIZE=512 -co BLOCKYSIZE=512 -co PHOTOMETRIC=YCBCR mosaic.vrt mosaic.tif gdaladdo mosaic.tif -r average --config COMPRESS_OVERVIEW JPEG --config JPEG_QUALITY_OVERVIEW 60 --config INTERLEAVE_OVERVIEW PIXEL --config PHOTOMETRIC_OVERVIEW YCBCR 2 4 8 16 32 64 128 256 512 Any ideas, tips or recommendations would be appreciated! Best regards, Ammar _ Sent from http://osgeo-org.1560.x6.nabble.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Reading CurveString and CurvePolygon Geometries from FGF Data
bob, if you decide to go the mask band route you wont be able to use a vrt. you will need to use gdalwarp or mapserver Brian On Tue, 2014-01-21 at 09:04 -0800, Bob Cave wrote: Even Rouault wrote Le vendredi 17 janvier 2014 17:08:38, Bob Cave a écrit : Hello, I am using the OGR Spatialite driver to read a database that has FGF geometries. Some of the geometries are CurvePolygons, which are not currently supported in OGRGeometryFactory::createFromFgfInternal() as of GDAL 1.10.1. Is support for FGF CurveString and CurvePolygon geometries currently in development? Not that I'm aware of. There's not yet support in OGR core for curve geometries, so that would be a preliminary step to implement support for the FGF curve geometries. This is something that could be part of the big changes for OGR 2.0 (http://trac.osgeo.org/gdal/wiki/GDAL20Changes). A few years ago I had started preliminary work in a sandbox but didn't pursue. Another annoying thing for implementation is that the link in http://trac.osgeo.org/fdo/wiki/FDORfc16 to the FGF binary spec seems to have disappeared. Do people actually use FDO SQLite databases ? Apparently, one of our customers uses an FDO SQLite database. I have seen that the OGR core does not currently support curve geometries, so these objects could not be handled that way. I was thinking that perhaps someone might be working on producing a polyline or polygon representation of an FGF curve object. I found the FGF Binary Specification here http://www.osgeo.org/files/fdo/docs/FDG_FDODevGuide/files/WSfacf1429558a55de8821c21057fbebc2b-789.htm . Thanks, Bob -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Reading-CurveString-and-CurvePolygon-Geometries-from-FGF-Data-tp5098667p5099296.html Sent from the GDAL - Dev mailing list archive at Nabble.com. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
