Serious bug in gdal_trace_outline (produces broken geometry) about dans-gdal-scripts HOT 7 CLOSED

gbb: is there any chance you could send me a copy of the raster image so that I can try and reproduce the problem?

Indeed, there were many changes made since Feb 2013, mostly having to do with gdal_trace_outline.

It is intentional that proj4 is not checked for anymore, since I now just use the proj4 which comes with GDAL.

from dans-gdal-scripts.

I've emailed you but it's not showing up here. Basically

Thanks very much for your help and quick reply. TIFF tile - should be fine but I have to ask my section leader and that will take until Thursday morning. Where is the best place to email it (probably 1MB)?

By the way, google for 'topologish' - you are welcome to make a raster of this million polygon simulated map and re-polygonise it using feb13 and current versions for comparison, if it's helpful. Probably a good test case to pick up bugs since it's pretty complex and a known topology.

from dans-gdal-scripts.

My email is [email protected], and 1MB should email fine. I could create a dropbox folder for a larger file.

So, from the pictures above, it looks like what's happening is that the right half of the tile is corrupted? It looks to me like maybe the raster data is getting corrupted before making it to the polygonizer. It looks like a television with bad hsync. But of course it's impossible to diagnose without a test case.

from dans-gdal-scripts.

Okay, fixed now. Actually, I'm amazed this didn't show up sooner. I was mistaken about how GDALReadBlock returns data for edge blocks. This bug would show up for any raster whose width was not a multiple of the block size.

from dans-gdal-scripts.

Excellent work Dan, thanks! Look forward to testing it out.

It's funny, there's a lot of people out there still using gdal_polygonize
who haven't heard about your scripts yet. I've been mentioning the scripts
to quite a few GIS people.

Perhaps it might be worth putting a post to one of the GDAL mailing lists
to let them know whenever there's a substantial group of changes grouped
together or a big bugfix?

Also, it might be worth tagging a version number onto some nodes of the git
history so that people can refer to them more easily (v1.1, 1.2...). It
would be helpful with bug reporting and it also helps people like myself
who are building other open source tools based on your work. :-)

Anyway thanks again and have a great weekend!

Graeme.

On Sat, Feb 7, 2015 at 8:14 PM, Dan Stahlke [email protected]
wrote:

Okay, fixed now. Actually, I'm amazed this didn't show up sooner. I was
mistaken about how GDALReadBlock returns data for edge blocks. This bug
would show up for any raster whose width was not a multiple of the block
size.

—
Reply to this email directly or view it on GitHub
#7 (comment)
.

from dans-gdal-scripts.

Also I'll test this out at the start of next week and let you know if
there's any other funny result.

On Sat, Feb 7, 2015 at 8:14 PM, Dan Stahlke [email protected]
wrote:

Okay, fixed now. Actually, I'm amazed this didn't show up sooner. I was
mistaken about how GDALReadBlock returns data for edge blocks. This bug
would show up for any raster whose width was not a multiple of the block
size.

—
Reply to this email directly or view it on GitHub
#7 (comment)
.

from dans-gdal-scripts.

I was doing version tags, just forgot to update them for a while. If
this bug fix works out, I'll tag it version 0.24. All my version
numbers are always less than one for some reason.

On 02/07/2015 01:40 PM, Graeme B Bell wrote:

Excellent work Dan, thanks! Look forward to testing it out.

It's funny, there's a lot of people out there still using gdal_polygonize
who haven't heard about your scripts yet. I've been mentioning the scripts
to quite a few GIS people.

Perhaps it might be worth putting a post to one of the GDAL mailing lists
to let them know whenever there's a substantial group of changes grouped
together or a big bugfix?

Also, it might be worth tagging a version number onto some nodes of
the git
history so that people can refer to them more easily (v1.1, 1.2...). It
would be helpful with bug reporting and it also helps people like myself
who are building other open source tools based on your work. :-)

Anyway thanks again and have a great weekend!

Graeme.

On Sat, Feb 7, 2015 at 8:14 PM, Dan Stahlke [email protected]
wrote:

Okay, fixed now. Actually, I'm amazed this didn't show up sooner. I was
mistaken about how GDALReadBlock returns data for edge blocks. This bug
would show up for any raster whose width was not a multiple of the block
size.

—
Reply to this email directly or view it on GitHub

#7 (comment)
.

—
Reply to this email directly or view it on GitHub
#7 (comment).

from dans-gdal-scripts.