[gdal-dev] Converting MDB File With Unicode Characters
Hey, I'm using a C# wrapper of GDAL and I'm having a problem converting MDB file that contains unicode characters. Lets take for example conversion to KML file, non-English characters are replaced by '?' How do I solve it? -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Converting-MDB-File-With-Unicode-Characters-tp5157110.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] Planning for 1.11.1 release ?
Hi, The 1.11 branch has accumulated 57 fixes [1] since the 1.11.0 release (perhaps a bit more if some of them went to the 1.10 branch as well), so it might be good to think producing a maintenance release with them. What do you think of end of September to produce an RC (let's say September 24th) ? If there are outstanding regressions that should be fixed for 1.11.1, raise tickets and cook up your patches ! There are 7 tickets currently opened against 1.11.1 milestone ([2]). GDAL committers, please have a look at them and update milestone if needed. Anyone volunteering to do the release process ? If nobody else wants, I will. Best regards, Even [1] http://trac.osgeo.org/gdal/query?status=closedgroup=resolutionorder=prioritymilestone=1.11.1resolution=fixed [2] http://trac.osgeo.org/gdal/query?status=assignedstatus=newstatus=reopenedgroup=resolutionorder=prioritycol=idcol=summarycol=ownercol=typecol=prioritycol=componentcol=versionmilestone=1.11.1 -- 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] Planning for 1.11.1 release ?
I wouldn't mind learning some of it, but would rather not being in charge of it. Thanks, Blake Thompson On Aug 19, 2014, at 8:53 AM, Even Rouault even.roua...@spatialys.com wrote: Hi, The 1.11 branch has accumulated 57 fixes [1] since the 1.11.0 release (perhaps a bit more if some of them went to the 1.10 branch as well), so it might be good to think producing a maintenance release with them. What do you think of end of September to produce an RC (let's say September 24th) ? If there are outstanding regressions that should be fixed for 1.11.1, raise tickets and cook up your patches ! There are 7 tickets currently opened against 1.11.1 milestone ([2]). GDAL committers, please have a look at them and update milestone if needed. Anyone volunteering to do the release process ? If nobody else wants, I will. Best regards, Even [1] http://trac.osgeo.org/gdal/query?status=closedgroup=resolutionorder=prioritymilestone=1.11.1resolution=fixed [2] http://trac.osgeo.org/gdal/query?status=assignedstatus=newstatus=reopenedgroup=resolutionorder=prioritycol=idcol=summarycol=ownercol=typecol=prioritycol=componentcol=versionmilestone=1.11.1 -- 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 mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Planning for 1.11.1 release ?
Selon Flippmoke flippm...@gmail.com: I wouldn't mind learning some of it, but would rather not being in charge of it. Hi Blake, The process is documented at http://svn.osgeo.org/gdal/trunk/gdal/HOWTO-RELEASE To issue the release itself, most steps that require commit rights and access to the OSGeo server. But there are other opportunities of helping, such as triaging tickets, proposing patches or testing release candidate. Even Thanks, Blake Thompson On Aug 19, 2014, at 8:53 AM, Even Rouault even.roua...@spatialys.com wrote: Hi, The 1.11 branch has accumulated 57 fixes [1] since the 1.11.0 release (perhaps a bit more if some of them went to the 1.10 branch as well), so it might be good to think producing a maintenance release with them. What do you think of end of September to produce an RC (let's say September 24th) ? If there are outstanding regressions that should be fixed for 1.11.1, raise tickets and cook up your patches ! There are 7 tickets currently opened against 1.11.1 milestone ([2]). GDAL committers, please have a look at them and update milestone if needed. Anyone volunteering to do the release process ? If nobody else wants, I will. Best regards, Even [1] http://trac.osgeo.org/gdal/query?status=closedgroup=resolutionorder=prioritymilestone=1.11.1resolution=fixed [2] http://trac.osgeo.org/gdal/query?status=assignedstatus=newstatus=reopenedgroup=resolutionorder=prioritycol=idcol=summarycol=ownercol=typecol=prioritycol=componentcol=versionmilestone=1.11.1 -- 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 mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- 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] Projection issues with PAMAP LiDAR
I recently ran into a projection problem with the PA LiDAR dataset and saw that Ticket #4954 documents the issue. Even had mentioned (in the forum thread linked in that Trac ticket) that he has a patch for this issue. I was just wondering if there were plans to include this in the 1.11.1 release. It is currently targeted to 1.11.0. Thanks, Alex ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Projection issues with PAMAP LiDAR
Selon Wood, Alexander aw...@agi.com: I recently ran into a projection problem with the PA LiDAR dataset and saw that Ticket #4954 documents the issue. Even had mentioned (in the forum thread linked in that Trac ticket) that he has a patch for this issue. Did I ? I can remember this issue is regularly raised but AFAIK nobody has produced a patch yet. I was just wondering if there were plans to include this in the 1.11.1 release. It is currently targeted to 1.11.0. Thanks, Alex -- 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] Questions about polygonization
I am trying to use GDAL's polygonize algorithms to help me identify regions in landcover data. I made a trivial example, but I am having trouble understanding the results that I get, nor can I determine how to get the results I want. Given the following raster: 11 11 11 11 11 11 11 11 11 11 11 11 12 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 If I were to polygonize this raster, I would expect two polygons: one which contains the single point 12, and another with an outer ring was the perimeter of the raster and an inner ring circling the single point 12. I would also expect that the first polygon would contain the single point 12 and that the second polygon would contain all the points 11. Instead, what I got was a polygon starting from the single point 12 and extending down and to the right one pixel, and another polygon with an outer ring that went off the down and right edges and an inner ring equal to the first polygon's outer ring. The first polygon doesn't actually contain any points and the second one doesn't contain any points on either ring but does contain all the other points. What do I need to do to get the results I am expecting? Jack. -- mathuin at gmail dot com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Questions about polygonization
Hi Jack,
I'm not sure if I understand the description of the shapes you see.
Can you provide the WKT for them? I seem to get two polygons that look
like they should:
import numpy as np
import rasterio.features
from shapely.geometry import shape
ar = np.ones((6, 5), 'B') * 11
ar[2, 2] = 12
gt = [0, 1, 0, 6, 0, -1]
for (sh, v) in rasterio.features.shapes(ar, transform=gt):
print('%s: %s' % (v, shape(sh)))
11: POLYGON ((0 6, 0 0, 5 0, 5 6, 0 6), (2 4, 3 4, 3 3, 2 3, 2 4))
12: POLYGON ((2 4, 2 3, 3 3, 3 4, 2 4))
-Mike
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Questions about polygonization
Jack, The GDALPolygonize algorithm draws the polygon edges along the pixel edges. It assumes the pixels to be rectangular areas instead of points. In the example you described, the first polygon should contain four vertices with the pixel in the centre. Make sure that the program you are using to display them is not shifting the pixels. On 20 Aug 2014 07:12, John Twilley math...@gmail.com wrote: I am trying to use GDAL's polygonize algorithms to help me identify regions in landcover data. I made a trivial example, but I am having trouble understanding the results that I get, nor can I determine how to get the results I want. Given the following raster: 11 11 11 11 11 11 11 11 11 11 11 11 12 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 If I were to polygonize this raster, I would expect two polygons: one which contains the single point 12, and another with an outer ring was the perimeter of the raster and an inner ring circling the single point 12. I would also expect that the first polygon would contain the single point 12 and that the second polygon would contain all the points 11. Instead, what I got was a polygon starting from the single point 12 and extending down and to the right one pixel, and another polygon with an outer ring that went off the down and right edges and an inner ring equal to the first polygon's outer ring. The first polygon doesn't actually contain any points and the second one doesn't contain any points on either ring but does contain all the other points. What do I need to do to get the results I am expecting? Jack. -- mathuin at gmail dot 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] Questions about polygonization
Hi Mike!
I get the same polygons you get -- what I don't understand is why I'm
getting those polygons instead of the ones that I expected. Can you
explain why those polygons look like they should?
Jack.
--
mathuin at gmail dot com
On Tue, Aug 19, 2014 at 7:15 PM, Mike Toews mwto...@gmail.com wrote:
Hi Jack,
I'm not sure if I understand the description of the shapes you see.
Can you provide the WKT for them? I seem to get two polygons that look
like they should:
import numpy as np
import rasterio.features
from shapely.geometry import shape
ar = np.ones((6, 5), 'B') * 11
ar[2, 2] = 12
gt = [0, 1, 0, 6, 0, -1]
for (sh, v) in rasterio.features.shapes(ar, transform=gt):
print('%s: %s' % (v, shape(sh)))
11: POLYGON ((0 6, 0 0, 5 0, 5 6, 0 6), (2 4, 3 4, 3 3, 2 3, 2 4))
12: POLYGON ((2 4, 2 3, 3 3, 3 4, 2 4))
-Mike
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Questions about polygonization
The program is not shifting the pixels, but the program does assume the pixels to be points and not rectangular areas so maybe I will have to shift the pixels. Do you know what transformation I would need to use? Jack. -- mathuin at gmail dot com On Tue, Aug 19, 2014 at 7:17 PM, Chaitanya kumar CH chaitanya...@gmail.com wrote: Jack, The GDALPolygonize algorithm draws the polygon edges along the pixel edges. It assumes the pixels to be rectangular areas instead of points. In the example you described, the first polygon should contain four vertices with the pixel in the centre. Make sure that the program you are using to display them is not shifting the pixels. On 20 Aug 2014 07:12, John Twilley math...@gmail.com wrote: I am trying to use GDAL's polygonize algorithms to help me identify regions in landcover data. I made a trivial example, but I am having trouble understanding the results that I get, nor can I determine how to get the results I want. Given the following raster: 11 11 11 11 11 11 11 11 11 11 11 11 12 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 If I were to polygonize this raster, I would expect two polygons: one which contains the single point 12, and another with an outer ring was the perimeter of the raster and an inner ring circling the single point 12. I would also expect that the first polygon would contain the single point 12 and that the second polygon would contain all the points 11. Instead, what I got was a polygon starting from the single point 12 and extending down and to the right one pixel, and another polygon with an outer ring that went off the down and right edges and an inner ring equal to the first polygon's outer ring. The first polygon doesn't actually contain any points and the second one doesn't contain any points on either ring but does contain all the other points. What do I need to do to get the results I am expecting? Jack. -- mathuin at gmail dot 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] Questions about polygonization
Try qgis to display the raster and the vector output. It shows the raster pixels as rectangular areas. To confirm that there is no shift, compare their extents using gdalinfo and ogrinfo. On 20 Aug 2014 07:56, John Twilley math...@gmail.com wrote: The program is not shifting the pixels, but the program does assume the pixels to be points and not rectangular areas so maybe I will have to shift the pixels. Do you know what transformation I would need to use? Jack. -- mathuin at gmail dot com On Tue, Aug 19, 2014 at 7:17 PM, Chaitanya kumar CH chaitanya...@gmail.com wrote: Jack, The GDALPolygonize algorithm draws the polygon edges along the pixel edges. It assumes the pixels to be rectangular areas instead of points. In the example you described, the first polygon should contain four vertices with the pixel in the centre. Make sure that the program you are using to display them is not shifting the pixels. On 20 Aug 2014 07:12, John Twilley math...@gmail.com wrote: I am trying to use GDAL's polygonize algorithms to help me identify regions in landcover data. I made a trivial example, but I am having trouble understanding the results that I get, nor can I determine how to get the results I want. Given the following raster: 11 11 11 11 11 11 11 11 11 11 11 11 12 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 If I were to polygonize this raster, I would expect two polygons: one which contains the single point 12, and another with an outer ring was the perimeter of the raster and an inner ring circling the single point 12. I would also expect that the first polygon would contain the single point 12 and that the second polygon would contain all the points 11. Instead, what I got was a polygon starting from the single point 12 and extending down and to the right one pixel, and another polygon with an outer ring that went off the down and right edges and an inner ring equal to the first polygon's outer ring. The first polygon doesn't actually contain any points and the second one doesn't contain any points on either ring but does contain all the other points. What do I need to do to get the results I am expecting? Jack. -- mathuin at gmail dot com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] RFC 15: Band Masks vs #5621
That question is probably for Even, Frank or some the developer of drivers that support mask band. I am working on ticket #5621 and trying to adapt it to the RFC 15 but I am not quite sure that I am getting it right. In GeoRaster, I can have a bitmap mask band that can be applied to all bands, similar to the concept of GMF_PER_DATASET, I guess. I can also have one bitmap mask band per raster band, but that does not correspond to the others mask flags (GMF_ALL_VALID, GMF_ALHA, GMF_NO_DATA). The data type of my bitmap mask is 1 bit, and there is no implicit connection with Alpha Channel or No Data in a binary bitmap mask, of course. So if I have a dataset with just one bitmap mask shared between all the bands, I think I can return the flag GMF_PER_DATASET and promote the values to GDT_BYTE. But if I have bitmap masks for each raster bands, then I don't know what flag to return. I might just lie and say GMF_PER_DATASET and when the mask is requested I will take care of returning the correct one. Would that works for others drivers participating on gdal_translate/CreateCopy()? Of course, if the output driver support just one mask per dataset, there is nothing much we can do. By the way, are there any driver that support overviews of mask band? Regards, Ivan ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
