[gdal-dev] Binding java : improve it or make a parser ?
Hi all, since some weeks i think about the improvement of the java binding. The fact is when you look at the javadoc and the gdal API doc, there's some difference between them. The model of the java binding is reduced at the minimum like geometry class. If i remember there was a discussion about ogr and the fact it was a little used. To make a mask with ogr and put it in dataset is not easy because the way is not obvious with the binding. And making a geometry is easier when you look at the geometry model. That's why i would like to improve the java binding but there's 2 ways : - the first is to modify swig interface. Even if i understand the code, the problem is i'm not a C/C++ developer. - the second is to make a parser like for XML or csv files in Java. For example i made an enum with gdal drivers to make an instance of driver. It's cleaner than to call it with a String and i added all information from the driver web page in the javadoc. The first question is : is it a good idea ? The aim of this project is to be used by others, not only me. The second is : which solution is better for you ? Regards, Florent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] gdal utilities question
I have been using the GDAL utilities. But ran into a snag. We create KML overlay files, basically KML file that geolocates a PNG on google maps. This PNG is a vector image as well as can have 1 or two colors other than the transparent background.We used gdal to convert this to a GEOTIFF using the gdal_contour and this work quite well, its ignores the colors for the most part, as all we want is a poly of the colored areas, don't care about what color. gedal_polygonize, sees all colors and seams much more rough. in both cases, we generate a KML shapefile, but it appears they create line entries vs polygons. We also use ogr2ogr to simplify the KML as well. Can anyone give me some better method to get a pologyon for only the colored areas , ignoring changes in color.? Dennis Burgess, ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdal utilities question
Dennis, You can create a new raster with the pixel values scaled to one bit so that all you have is zero for no color and one for any color. Use gdal_translate with the -scale option. The exact method depends on the data. Then you are essentially ignoring the color. Contours are set as lines instead of polygons because they terminate at the raster edges. -- Best regards, Chaitanya Kumar CH On Dec 11, 2013 9:48 PM, Dennis Burgess dmburg...@linktechs.net wrote: I have been using the GDAL utilities. But ran into a snag. We create KML overlay files, basically KML file that geolocates a PNG on google maps. This PNG is a vector image as well as can have 1 or two colors other than the transparent background.We used gdal to convert this to a GEOTIFF using the gdal_contour and this work quite well, its ignores the colors for the most part, as all we want is a poly of the colored areas, don't care about what color. gedal_polygonize, sees all colors and seams much more rough. in both cases, we generate a KML shapefile, but it appears they create line entries vs polygons. We also use ogr2ogr to simplify the KML as well. Can anyone give me some better method to get a pologyon for only the colored areas , ignoring changes in color.? *Dennis Burgess,* ___ 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] Default GeoTransform for MEM driver
On Tue, Dec 10, 2013 at 12:44 PM, Even Rouault even.roua...@mines-paris.org wrote: Le mardi 10 décembre 2013 16:48:31, Ivan Lucena a écrit : Hi Even, From: even.roua...@mines-paris.org To: gdal-dev@lists.osgeo.org Subject: Re: [gdal-dev] Default GeoTransform for MEM driver Date: Mon, 9 Dec 2013 20:54:35 +0100 CC: lucena_i...@hotmail.com; tke...@utexas.edu; jukka.rahko...@mmmtike.fi Le lundi 09 décembre 2013 18:08:19, Ivan Lucena a écrit : The other problem with that documentation is the return code. CE_Failue means that the driver does not support it and/or that the dataset doesn't have it. The current behaviour of the MEM driver doesn't particularly shock me. It seems OK to return CE_Failure if SetGeoTransform() hasn't been explicitely called to define it. And as far as the default geotransform, it is a matter of taste. [ 0, 1, 0, 0, 0, 1] would be indeed a bit more classical for a ungeoreferenced image, but one can consider that if GetGeoTransform() returns CE_Failure, the returned geotransform is to be ignored. That is good to know. So it really doesn't matter if the driver support geotransformation or not. But my concern is when it returns CE_None. What does it really means because I was checking some driver's implementation of GetGeoTransform and I noticed that some of then always return CE_None no matter what. So would that be possible that a dataset is *ungeoreferenced* and a driver returns CE_None with the default values [0, 1, 0, 0, 0, 1]. Should we trust that those values [0, 1, 0, 0, 0, 1] are correct or are they just a default filler? For example, to get [0, 1, 0, 0, 0, 1] we should expect a world-file that should be something like: 1.00 0.00 0.00 1.00 0.50 0.50 Not: 1.00 0.00 0.00 1.00 0.00 0.00 Anyway, I will trust that the CE_None means that the geotransformation values are correct but should I will also check if the values are equal to [0, 1, 0, 0, 0, 1] just in case? And what to do if they are? I'm not sure to know the ultimate answer to your questions. My understanding of http://www.gdal.org/classGDALDataset.html#af9593cc241e7d140f5f3c4798a43a668 is that when there's no projection space associated to a raster, it should return (0,1,0,0,0,1) and CE_Failure. But they are certainly drivers that return (0,1,0,0,0,1) and CE_None. They should likely be fixed to return CE_Failure instead. But you can also test if the geotransform is (0,1,0,0,0,1) since it isn't a likely real geotransform. It would make things easier if all drivers returned the same default: (0, 1, 0, 0, 0, -1) for any dataset where the transform has not been assigned. (I reworked my test to use the assumption that spatial y and line index y are opposite sign and it works correctly.) I think it should be considered a bug in the docs and any driver the does not return that default. Otherwise users have to add a lot of ugly conditional code. THK Even -- Geospatial professional services http://even.rouault.free.fr/services.html -- http://www.keittlab.org/ ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Default GeoTransform for MEM driver
Le mercredi 11 décembre 2013 19:23:09, Tim Keitt a écrit : On Tue, Dec 10, 2013 at 12:44 PM, Even Rouault even.roua...@mines-paris.org wrote: Le mardi 10 décembre 2013 16:48:31, Ivan Lucena a écrit : Hi Even, From: even.roua...@mines-paris.org To: gdal-dev@lists.osgeo.org Subject: Re: [gdal-dev] Default GeoTransform for MEM driver Date: Mon, 9 Dec 2013 20:54:35 +0100 CC: lucena_i...@hotmail.com; tke...@utexas.edu; jukka.rahko...@mmmtike.fi Le lundi 09 décembre 2013 18:08:19, Ivan Lucena a écrit : The other problem with that documentation is the return code. CE_Failue means that the driver does not support it and/or that the dataset doesn't have it. The current behaviour of the MEM driver doesn't particularly shock me. It seems OK to return CE_Failure if SetGeoTransform() hasn't been explicitely called to define it. And as far as the default geotransform, it is a matter of taste. [ 0, 1, 0, 0, 0, 1] would be indeed a bit more classical for a ungeoreferenced image, but one can consider that if GetGeoTransform() returns CE_Failure, the returned geotransform is to be ignored. That is good to know. So it really doesn't matter if the driver support geotransformation or not. But my concern is when it returns CE_None. What does it really means because I was checking some driver's implementation of GetGeoTransform and I noticed that some of then always return CE_None no matter what. So would that be possible that a dataset is *ungeoreferenced* and a driver returns CE_None with the default values [0, 1, 0, 0, 0, 1]. Should we trust that those values [0, 1, 0, 0, 0, 1] are correct or are they just a default filler? For example, to get [0, 1, 0, 0, 0, 1] we should expect a world-file that should be something like: 1.00 0.00 0.00 1.00 0.50 0.50 Not: 1.00 0.00 0.00 1.00 0.00 0.00 Anyway, I will trust that the CE_None means that the geotransformation values are correct but should I will also check if the values are equal to [0, 1, 0, 0, 0, 1] just in case? And what to do if they are? I'm not sure to know the ultimate answer to your questions. My understanding of http://www.gdal.org/classGDALDataset.html#af9593cc241e7d140f5f3c4798a43a6 68 is that when there's no projection space associated to a raster, it should return (0,1,0,0,0,1) and CE_Failure. But they are certainly drivers that return (0,1,0,0,0,1) and CE_None. They should likely be fixed to return CE_Failure instead. But you can also test if the geotransform is (0,1,0,0,0,1) since it isn't a likely real geotransform. It would make things easier if all drivers returned the same default: (0, 1, 0, 0, 0, -1) for any dataset where the transform has not been assigned. (I reworked my test to use the assumption that spatial y and line index y are opposite sign and it works correctly.) I think it should be considered a bug in the docs and any driver the does not return that default. Otherwise users have to add a lot of ugly conditional code. I don't see where there's a bug in the documentation. (0,1,0,0,0,1) is OK for the default geotransform. It means that spatial coordinate space = raster coordinate space. It is the geotransform (0,1,0,0,0,-1) of the MEM driver that is a bit odd. Patches welcome to unify driver behaviour. THK Even -- Geospatial professional services http://even.rouault.free.fr/services.html -- Geospatial professional services http://even.rouault.free.fr/services.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
