from:"CABO"

[gdal-dev] Python error (missing?) when performing RasterizeLayer on specific polygon with two very close vertices

2014-09-09 Thread CABO

I have the following polygon:

POLYGON ((539500.4634191 6314429.5954758488,539499.999 
6314429.5964747742,539500.0 6314500.001,539563.49086194986 
6314500.001,539574.70556674246 6314491.5008581309,539591.23494657199 
6314478.9664945751,539600.001 6314472.1168122729,539600.00014411798 
6314460.5601839637,539543.07124903298 6314452.2691510962,539546.30058158806 
6314438.619163854,539507.3702219734 6314429.939004397,539505.68004823104 
6314429.8589810915,539500.4634191 6314429.5954758488))

I have created a memory vector layer and added this polygon as the only feature.

projection = ...
geometry = ...
ogr_mem_drv = ogr.GetDriverByName('Memory')

mem_vector_ds = ogr_mem_drv.CreateDataSource('')
mem_vector_layer = mem_vector_ds.CreateLayer('', srs=projection)
feature = ogr.Feature(mem_vector_layer.GetLayerDefn())
feature.SetGeometry(geometry.Clone())
mem_vector_layer.CreateFeature(feature)

gdal_mem_drv = gdal.GetDriverByName('MEM')
mem_raster_ds = gdal_mem_drv.Create('',5,5,1,gdal.GDT_Byte)
mem_raster_ds.SetGeoTransform([...])
mem_raster_ds.SetProjection(mem_vector_layer.GetSpatialRef().ExportToWkt())

err = gdal.RasterizeLayer(mem_raster_ds, [1], mem_vector_layer, None, None, 
[1], ['ALL_TOUCHED=TRUE'])

When running the last line with gdal.RasterizeLayer(...) my program waits a 
couple of seconds and then just terminates without any exception or error.

If  I remove vertex number two from the above WKT it works. Vertex 1 and 2 are 
very close (located in the lower left corner of the polygon).

I am running GDAL 1.10.1 and Python 3.2, builds are stable releases from 
http://www.gisinternals.com/sdk/.

What could be the reason for this strange error?


Kind regards, Casper
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Python error (missing?) when performing RasterizeLayer on specific polygon with two very close vertices

2014-09-09 Thread CABO

I have tried with GDAL 1.11 and Python 3.2 (again the builds are from 
GISInternals), and it gives me the same result. Python just terminated without 
any warning or error.

Both versions of GDAL are x64.


Kind regards, Casper

From: gdal-dev-boun...@lists.osgeo.org 
[mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Casper Børgesen (CABO)
Sent: 9. september 2014 17:16
To: gdal-dev@lists.osgeo.org
Subject: [gdal-dev] Python error (missing?) when performing RasterizeLayer on 
specific polygon with two very close vertices

I have the following polygon:

POLYGON ((539500.4634191 6314429.5954758488,539499.999 
6314429.5964747742,539500.0 6314500.001,539563.49086194986 
6314500.001,539574.70556674246 6314491.5008581309,539591.23494657199 
6314478.9664945751,539600.001 6314472.1168122729,539600.00014411798 
6314460.5601839637,539543.07124903298 6314452.2691510962,539546.30058158806 
6314438.619163854,539507.3702219734 6314429.939004397,539505.68004823104 
6314429.8589810915,539500.4634191 6314429.5954758488))

I have created a memory vector layer and added this polygon as the only feature.

projection = ...
geometry = ...
ogr_mem_drv = ogr.GetDriverByName('Memory')

mem_vector_ds = ogr_mem_drv.CreateDataSource('')
mem_vector_layer = mem_vector_ds.CreateLayer('', srs=projection)
feature = ogr.Feature(mem_vector_layer.GetLayerDefn())
feature.SetGeometry(geometry.Clone())
mem_vector_layer.CreateFeature(feature)

gdal_mem_drv = gdal.GetDriverByName('MEM')
mem_raster_ds = gdal_mem_drv.Create('',5,5,1,gdal.GDT_Byte)
mem_raster_ds.SetGeoTransform([...])
mem_raster_ds.SetProjection(mem_vector_layer.GetSpatialRef().ExportToWkt())

err = gdal.RasterizeLayer(mem_raster_ds, [1], mem_vector_layer, None, None, 
[1], ['ALL_TOUCHED=TRUE'])

When running the last line with gdal.RasterizeLayer(...) my program waits a 
couple of seconds and then just terminates without any exception or error.

If  I remove vertex number two from the above WKT it works. Vertex 1 and 2 are 
very close (located in the lower left corner of the polygon).

I am running GDAL 1.10.1 and Python 3.2, builds are stable releases from 
http://www.gisinternals.com/sdk/.

What could be the reason for this strange error?


Kind regards, Casper
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Is OGR Buffer(...) thread safe in C#?

2016-07-04 Thread CABO

Hi

I was just trying to parallelize buffering of a large set of polygons using 
GDAL 2.1 in C#.
My code is something like the following:

List polygonList = List of polygons...
var result = new ConcurrentBag();

Parallel.ForEach(polygonList, polygon =>
{
var polygonBuffer = polygon.Buffer(1, 1);
   result.Add(polygonBuffer);
});

I get a System.AccessViolationException in ogr_csharp.dll on the Buffer(...) 
line. Since my method runs fine using a normal foreach or if I omit the 
Buffer(...) method, I assume it has something to do with thread safety and OGR.

So is my problem just that OGR Buffer(...) isn't thread safe or am I doing 
something wrong here?

Regards, Casper
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Strange results of simple polygonising

2017-01-19 Thread CABO

Hi,

I have four simple rasters that I would like to polygonise:

1:
# # #
##
# #

2:
# #
# #
# # #

3:
# #
# #
# # #

4:
# # #
##
   # #

It's the same shape, just rotated 90, 180, 270 degrees. The resulting polygons 
for 1 and 2 are simple polygons without holes, where the results for 3 and 4 
are polygons with a hole intersecting the exterior ring. Thus 3 and 4 results 
in invalid geometries with self-intersection.

Is this the intended behavior of the polygoniser?


Regards, Casper
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] FW: Strange results of simple polygonising

2017-01-20 Thread CABO

I have looked at the special case of a raster combining situation 3 and 4 below:

3 + 4:
   # #
##
##
  #  #

The polygoniser handles this fine by return a result with two separate polygons.

For easier reference, I have included the WKT of the 4 + 1 situations and their 
results:

1:
Input:   POLYGON ((1 1,3 1,3 2,2 2,2 3,3 3,3 2,4 2,4 4,1 4,1 1))
Result: POLYGON ((1 4,1 1,3 1,3 2,2 2,2 3,3 3,3 2,4 2,4 4,1 4))

2:
Input:   POLYGON ((1 1,4 1,4 3,3 3,3 2,2 2,2 3,3 3,3 4,1 4,1 1))
Result: POLYGON ((1 4,1 1,4 1,4 3,3 3,3 2,2 2,2 3,3 3,3 4,1 4))

3:
Input:   POLYGON ((1 1,4 1,4 4,2 4,2 3,3 3,3 2,2 2,2 3,1 3,1 1))
Result: POLYGON ((2 4,2 3,1 3,1 1,3 1,4 1,4 4,2 4),(2 3,2 2,3 2,3 3,2 3))

4:
Input:   POLYGON ((1 4,1 2,2 2,2 3,3 3,3 2,2 2,2 1,4 1,4 4,1 4))
Result: POLYGON ((1 4,1 2,2 2,2 1,4 1,4 4,1 4),(2 3,3 3,3 2,2 2,2 3))

3 + 4:
Input:   MULTIPOLYGON (((1 2,2 2,2 4,1 4,1 2)),((2 1,4 1,4 5,2 5,2 4,3 4,3 2,2 
2,2 1)))
Result: POLYGON ((1 4,1 2,2 2,2 4,1 4)) + POLYGON ((2 5,2 4,3 4,3 2,2 2,2 1,3 
1,4 1,4 5,2 5))

I have performed the tests on both GDAL 1.11 and GDAL 2.1 and both return the 
same results.

Can anyone confirm my observations?

Background: The 4 situations are very simplified versions of much more 
complicated polygons, where the problem occurs. If I save the results from 
situation 3 or 4 to a shape file with ogr, the hole in the results are 
converted to an exterior ring in a separate polygon thus creating overlapping 
results.

Regards, Casper

From: gdal-dev [mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Casper 
Børgesen (CABO)
Sent: 19. januar 2017 13:26
To: gdal-dev@lists.osgeo.org
Subject: [gdal-dev] Strange results of simple polygonising

Hi,

I have four simple rasters that I would like to polygonise:

1:
# # #
##
# #

2:
# #
# #
# # #

3:
# #
# #
# # #

4:
# # #
##
   # #

It's the same shape, just rotated 90, 180, 270 degrees. The resulting polygons 
for 1 and 2 are simple polygons without holes, where the results for 3 and 4 
are polygons with a hole intersecting the exterior ring. Thus 3 and 4 results 
in invalid geometries with self-intersection.

Is this the intended behavior of the polygoniser?


Regards, Casper
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Don't we have any ideas for GSoC 2017?

2017-02-28 Thread CABO

Hi,

I don't know if the idea is too simple, but implementing indexing on VRT files 
would be great to have. I thinks it's currently a feature request.


Regards, Casper


-Original Message-
From: gdal-dev [mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Rahkonen 
Jukka (MML)
Sent: 28. februar 2017 09:07
To: 'gdal-dev@lists.osgeo.org' (gdal-dev@lists.osgeo.org)
Subject: [gdal-dev] Don't we have any ideas for GSoC 2017?

Hi,

OSGeo is accepted as an organization for the Google Summer of Code 2017 but 
there are no GDAL related ideas on 
https://wiki.osgeo.org/wiki/Google_Summer_of_Code_2017_Ideas. Could we raise 
some of the old ideas or discover some brand new ones?

-Jukka Rahkonen-
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] FW: Don't we have any ideas for GSoC 2017?

2017-03-01 Thread CABO

Yes this is about spatial indexing :)

Without looking at the actual VRT code I would guess that parsing the VRT file 
is one thing, but having a VRT file with +100,000 tiles would require GDAL to 
look through each tile every time a pixel is requested?
Even, if your idea below could be implemented into the VRT driver to be able to 
build the index file and gdaladdo to build the overview index files, it would 
be a huge step forward.

Is it possible to build the index on the fly into memory when opening the VRT 
file? Is it too memory or time consuming?

/Casper

From: gdal-dev [mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Even 
Rouault
Sent: 1. marts 2017 13:25
To: gdal-dev@lists.osgeo.org
Cc: Rahkonen Jukka (MML)
Subject: Re: [gdal-dev] FW: Don't we have any ideas for GSoC 2017?


On mercredi 1 mars 2017 11:43:12 CET Rahkonen Jukka (MML) wrote:

> Forwarding to the list because Jordan's trial was not successful.



Sounds a good idea. I think potential students should be more pro-active in 
proposing and developing their own ideas.



Regarding "indexing on VRT files", I guess this is about spatial indexing of 
sources in a VRT file. My bet would be that the size of VRT files that would 
need such indexing would be so large than their parsing would be the most 
limiting factor. But I can be wrong.

Some people who want to make a mosaic from a huge number of tiles do that by 
making VRTs of VRTs of VRTs with a pyramid structure to avoid parsing a lot of 
XML and still having good performance.

Another option that has been mentionned in the past would be to have a 
variation of the VRT syntax that would reference a tile index (shapefile or any 
OGR datasource) and would thus benefit from its spatial indexing & filtering 
capabilities



Something like:





EPSG:26711

 4.4072e+05, 6.e+01, 
0.e+00, 3.75132000e+06, 0.e+00, 
-6.e+01



index.shp









index_ovr_2.shp









index_ovr_4.shp







Red





Green





Blue







Even
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] gdalbuildvrt problem with heterogenous band characteristics

2012-07-30 Thread CABO

Hi!

I'm trying to create a VRT file from 4 GeoTIFFs using gdalbuildvrt. Three of 
the GeoTIFFs are created using OrthoVista and the last one created with an 
earlier version of the same program. When I run gdalbuildvrt I get the 
following error message when I try to add the file created by the early version:

Warning 6: gdalbuildvrt does not support heterogenous band characteristics. 
Skipping...

Running gdalinfo on the 4 files I see only a difference in the metadata section 
(and of course in the coordinates).
In the following is the band information from two of the files:

[From new version]
Band 1 Block=6250x20 Type=Byte, ColorInterp=Red
  Overviews: 1024x1024
Band 2 Block=6250x20 Type=Byte, ColorInterp=Green
  Overviews: 1024x1024
Band 3 Block=6250x20 Type=Byte, ColorInterp=Blue
  Overviews: 1024x1024
Band 4 Block=6250x20 Type=Byte, ColorInterp=Undefined
  Overviews: 1024x1024

[From earlier version]
Band 1 Block=6250x20 Type=Byte, ColorInterp=Red
  Overviews: 1024x1024
Band 2 Block=6250x20 Type=Byte, ColorInterp=Green
  Overviews: 1024x1024
Band 3 Block=6250x20 Type=Byte, ColorInterp=Blue
  Overviews: 1024x1024
Band 4 Block=6250x20 Type=Byte, ColorInterp=Undefined
  Overviews: 1024x1024

To me they seem identical and I can display them both using QGis 1.8. I guess 
that the difference is deeper inside the TIFFs than gdalinfo informs me about - 
what can I do to avoid this problem?

Regards Casper
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] gdalbuildvrt problem with heterogenous band characteristics

2012-07-31 Thread CABO

What do you mean by manually? I run gdalbuildvrt using the command line, so I 
don’t understand how it can be done more manually ☺

gdalbuildvrt myfile.vrt file1.tif file2.tif file3.tif file4.tif

I have tried using an old version of gdalinfo (1.7.0) and it gives tells me 
that my first 3 bands in the old file contains a mask flag:

Mask Flags: PER_DATASET ALPHA

This flag is not present in the 3 new files. Could this be the reason?

Btw. my normal version of gdal is 1.9.

Regards, Casper

From: Chaitanya kumar CH [mailto:chaitanya...@gmail.com]
Sent: 31. juli 2012 15:30
To: Casper Børgesen (CABO)
Cc: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] gdalbuildvrt problem with heterogenous band 
characteristics

Casper,

This message should not appear unless there is a difference in the band data 
type, colour interpretation or the band order.
Can you check if manually adding the old file works?
On Mon, Jul 30, 2012 at 11:01 PM, Casper Børgesen (CABO) 
mailto:c...@niras.dk>> wrote:
Hi!

I’m trying to create a VRT file from 4 GeoTIFFs using gdalbuildvrt. Three of 
the GeoTIFFs are created using OrthoVista and the last one created with an 
earlier version of the same program. When I run gdalbuildvrt I get the 
following error message when I try to add the file created by the early version:

Warning 6: gdalbuildvrt does not support heterogenous band characteristics. 
Skipping...

Running gdalinfo on the 4 files I see only a difference in the metadata section 
(and of course in the coordinates).
In the following is the band information from two of the files:

[From new version]
Band 1 Block=6250x20 Type=Byte, ColorInterp=Red
  Overviews: 1024x1024
Band 2 Block=6250x20 Type=Byte, ColorInterp=Green
  Overviews: 1024x1024
Band 3 Block=6250x20 Type=Byte, ColorInterp=Blue
  Overviews: 1024x1024
Band 4 Block=6250x20 Type=Byte, ColorInterp=Undefined
  Overviews: 1024x1024

[From earlier version]
Band 1 Block=6250x20 Type=Byte, ColorInterp=Red
  Overviews: 1024x1024
Band 2 Block=6250x20 Type=Byte, ColorInterp=Green
  Overviews: 1024x1024
Band 3 Block=6250x20 Type=Byte, ColorInterp=Blue
  Overviews: 1024x1024
Band 4 Block=6250x20 Type=Byte, ColorInterp=Undefined
  Overviews: 1024x1024

To me they seem identical and I can display them both using QGis 1.8. I guess 
that the difference is deeper inside the TIFFs than gdalinfo informs me about – 
what can I do to avoid this problem?

Regards Casper

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/gdal-dev



--
Best regards,
Chaitanya kumar CH.

+91-9494447584
17.2416N 80.1426E
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] C# Bindings: RasterizeLayer

2012-10-12 Thread CABO

I am trying to use the OSGeo.GDAL.Gdal.RasterizeLayer(...) and it requires some 
SWIGTYPE parameters.

Reading up on some old mails somewhere regarding ReadRaster and WriteRaster, 
Tamaz states that methods requesting SWIGTYPE parameters, cannot be used (yet). 
Does this mean that the RasterizeLayer method hasn't been ported to the C# 
bindings or are there some clever stuff that I don't know about?

Regards Casper


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] C#: Simple geometry loading

2012-10-21 Thread CABO

Hi!

I have this very simple problem which I don't understand. I am loading a shape 
file (multipolygon) and copying the geometry into a new structure:

OSGeo.OGR.Geometry geometries = new 
OSGeo.OGR.Geometry(OSGeo.OGR.wkbGeometryType.wkbMultiPolygon);

OSGeo.OGR.DataSource dataSource = OSGeo.OGR.Ogr.Open(filename, 0);
OSGeo.OGR.Layer layer = dataSource.GetLayerByIndex(0);
OSGeo.OGR.Feature currentFeature = null;
layer.ResetReading();
while ((currentFeature = layer.GetNextFeature()) != null)
{
string wkt = string.Empty;
currentFeature.GetGeometryRef().ExportToWkt(out wkt); --> 
MULTIPOLYGON (((476587.2 6100012.8,  ,533324.8 6190163.2)))
geometries.AddGeometry(currentFeature.GetGeometryRef());
string wkt2 = string.Empty;
geometries.ExportToWkt(out wkt2); --> MULTIPOLYGON EMPTY
}
dataSource.Dispose();

Am I doing something completely wrong here?

I just want all of the geometry in the input file put into the variable 
geometries for later use.

The input data is a rather large data set and before I try to strip it down, I 
just want to know if my approach is wrong or if I can expect this to be working.

GDAL/OGR version: 1.9.2, C# bindings from Tamas daily builds.

Regards Casper





___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] GDAL: RasterizeLayer in C#

2012-10-25 Thread CABO

Hi all,

I am trying to use the OSGeo.GDAL.Gdal.RasterizeLayer() from GDAL 1.9.2 and it 
seems to require some SWIGTYPE parameters, which I don't know what to do with:

OSGeo.GDAL.Gdal.RasterizeLayer(
OSGeo.GDAL.Dataset dataset,
int bands,
OSGeo.GDAL.SWIGTYPE_p_int band_list,
OSGeo.OGR.Layer layer,
OSGeo.GDAL.SWIGTYPE_p_void pfnTransformer,
OSGeo.GDAL.SWIGTYPE_p_void pTransformArg,
int burn_values,
OSGeo.GDAL.SWIGTYPE_p_double burn_values_list,
string[] options,
OSGeo.GDAL.Gdal.GDALProgressFuncDelegate callback,
string callback_data
);

Looking at the source I can trace this method to swig\csharp\gdal\gdal.cs and 
from there it's outside the range of my capabilities.

Can anyone describe for me how to use this method, or maybe just tell me that 
this method is not usable in C# at the moment and if it's going to change?

Sorry for reposting, but I would really like to know :)


Regards, Casper
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Is there any way of accesing the GDAL utilities from C#?

2012-11-07 Thread CABO

I have created the ticket:

http://trac.osgeo.org/gdal/ticket/4888


Best regards,

Casper

From: gdal-dev-boun...@lists.osgeo.org 
[mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Tamas Szekeres
Sent: 7. november 2012 10:41
To: Dev3
Cc: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Is there any way of accesing the GDAL utilities from C#?

With regards to the C# bindings Gdal.FillNodata should work, but 
Gdal.RasterizeLayer requires some adjustments. You might file a ticket for this 
at http://trac.osgeo.org/gdal/newticket

Best regards,

Tamas


2012/11/7 Dev3 mailto:devda...@tengshe.in>>
Hi All!
I am trying to do some data processing in my .NET application. I have found
that my work is done by using just two of the gdal utilities: gdal_rasterize
& gdal_fillnodata.

However, when I downloaded the C# bindings, I realized that the utilities
are not part of it. Is there any quick way of getting the utilities from C#,
or will it be quicker to just use System.Diagnostics.Process.Start() method,
to run the gdal Utilities on the command line?



--
View this message in context: 
http://osgeo-org.1560.n6.nabble.com/Is-there-any-way-of-accesing-the-GDAL-utilities-from-C-tp5014441.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

[gdal-dev] Inifitine recursion in ogr.py

2012-11-13 Thread CABO

Hi!

I am using GDAL 1.9.2 x64, Python 3.3 x64 and Windows 7 and I have a problem 
with infinite recursion in ogr.py. My initial call is:

feature = ogr.Feature(layer.GetLayerDefn())

and the call stack:

__init__

Python\lib\site-packages\osgeo\ogr.py

__getattr__

Python\lib\site-packages\osgeo\ogr.py

GetField

Python\lib\site-packages\osgeo\ogr.py

GetFieldIndex

Python\lib\site-packages\osgeo\ogr.py

__getattr__

Python\lib\site-packages\osgeo\ogr.py

GetField

Python\lib\site-packages\osgeo\ogr.py

... repeating...

...


I have tried using Eclipse 4.2 with Pydev 2.7 and PyScripter 2.5.3, and in both 
cases the debug functionality is messed up after the above initial call. When 
just running the script, no problems occur.
What can I do to avoid this problem?


Best regards

Casper
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] ImportError when importing gdal module with python 2.7 on Windows 7 64-bit

2012-11-15 Thread CABO

I usually struggle with the same problems over and over again. Try using 
Dependency Walker (http://www.dependencywalker.com/) to see if you are missing 
a library or two. I used it to determine that I was missing these two files: 

msvcp100.dll
msvcr100.dll

I remember something about Microsoft removing these during some updates. They 
might be needed in your path.

I don't know if that helps :)

Regards, Casper

-Original Message-
From: gdal-dev-boun...@lists.osgeo.org 
[mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of nnneogeorge
Sent: 15. november 2012 18:59
To: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] ImportError when importing gdal module with python 2.7 
on Windows 7 64-bit

Hey guys, 

I am using the python 2.7.3 64b, with the GDAL 64b (tried both 19 & 20
versions) under windows 7 64b, I have followed all the steps here

http://www.gis.usu.edu/~chrisg/python/2009/docs/gdal_win.pdf

and here

http://pythongisandstuff.wordpress.com/2011/07/07/installing-gdal-and-ogr-for-python-on-windows/

took the software from here 

http://www.lfd.uci.edu/~gohlke/pythonlibs/
http://www.gisinternals.com/sdk/PackageList.aspx?file=release-1400-x64-gdal-mapserver.zip
 

And experimented with all the possible folder paths, added in the Environmental 
Variable... the modules osGEo and gdal are both in the list of python (I can 
check through > help ("modules") , but when I ask for more information on 
these, it throws the following error 

##
problem in osgeo - : DLL load failed: The 
specified module could not be found.
##



ofcourse the same goes when I try to import gdal ,I m getting the following
message: 


Traceback (most recent call last):
File "", line 1, in 
import gdal
File "C:\Python27\lib\gdal.py", line 2, in  from osgeo.gdal import 
deprecation_warn File "C:\Python27\lib\osgeo\__init__.py", line 21, in  
_gdal = swig_import_helper() File "C:\Python27\lib\osgeo\__init__.py", line 17, 
in swig_import_helper _mod = imp.load_module('_gdal', fp, pathname, description)
ImportError: DLL load failed: The specified module could not be found.


Which I guess should understand that the dll that supposed to be created, well 
hasnt... 

Checked manually and yeap its true, couldnt find it - 

Then I tried to check if the path was right for sure, so opening the windows 
console and typing "set" gave me the list with the path variables --> all 
right. 

Also the osgeo command-line works perfectly fine. 

Any ideas or things to try more than welcome... 

Thanks a lot, 

George. 




--
View this message in context: 
http://osgeo-org.1560.n6.nabble.com/gdal-dev-ImportError-when-importing-gdal-module-with-python-2-7-on-Windows-7-64-bit-tp5006198p5016723.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

[gdal-dev] C# ogr_wrap.dll exception with ogr.OGRERR_NONE

2013-04-05 Thread CABO

I am experiencing some problems with C# and GDAL/OGR.
I have a program where I just initialize GDAL/OGR with this command:

OSGeo.OGR.Ogr.AllRegister();

// Here follows some IO and data processing, and its working just fine.

Now I add a simple line to my program:

OSGeo.OGR.Ogr.AllRegister();
var a = OSGeo.OGR.Ogr.OGRERR_NONE

// Here follows some IO and data processing, and it used to be working.

The type initializer for 'OSGeo.OGR.Ogr' threw an exception.
...The type initializer for 'OSGeo.OGR.OgrPINVOKE' threw an exception.
.. The type initializer for 'SWIGExceptionHelper' threw an exception.
. Unable to load DLL 'ogr_wrap': The specified module could not be 
found. (Exception from HRESULT: 0x8007007E)

Can anyone push me in the right direction so I can determine why using 
Ogr.OGRERR_NONE would break my program?

Regards Casper
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] C# ogr_wrap.dll exception with ogr.OGRERR_NONE

2013-04-05 Thread CABO

Maybe I should state that I'm using GDAL 1.9.2 with VS2010.

From: gdal-dev-boun...@lists.osgeo.org 
[mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Casper Børgesen (CABO)
Sent: 5. april 2013 10:07
To: gdal-dev@lists.osgeo.org
Subject: [gdal-dev] C# ogr_wrap.dll exception with ogr.OGRERR_NONE

I am experiencing some problems with C# and GDAL/OGR.
I have a program where I just initialize GDAL/OGR with this command:

OSGeo.OGR.Ogr.AllRegister();

// Here follows some IO and data processing, and its working just fine.

Now I add a simple line to my program:

OSGeo.OGR.Ogr.AllRegister();
var a = OSGeo.OGR.Ogr.OGRERR_NONE

// Here follows some IO and data processing, and it used to be working.

The type initializer for 'OSGeo.OGR.Ogr' threw an exception.
...The type initializer for 'OSGeo.OGR.OgrPINVOKE' threw an exception.
.. The type initializer for 'SWIGExceptionHelper' threw an exception.
. Unable to load DLL 'ogr_wrap': The specified module could not be 
found. (Exception from HRESULT: 0x8007007E)

Can anyone push me in the right direction so I can determine why using 
Ogr.OGRERR_NONE would break my program?

Regards Casper
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Polygonize + 8conn => self intersection?

2013-05-02 Thread CABO

Hi all.

I've got a simple question. When using GDAL Polygonize with 8-connectivity on 
two diagonal pixels (the X's) like this:

X +
+ X

Does this lead to a single polygon with self intersection or a multipolygon 
with two single polygons?

It seems to give me a single polygon regardless of the geometry type of the 
output layer.

Regards, Casper
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] GDAL v.1.10 and Python 3.3.2 - incompatible?

2013-07-02 Thread CABO

Hi everyone.

I’m trying to setup GDAL 1.10 and python 3.3.2 using the following binaries:

GDAL:
http://www.gisinternals.com/sdk/Download.aspx?file=release-1600-x64-gdal-mapserver\gdal-110-1600-x64-core.msi
Python: http://www.python.org/ftp/python/3.3.2/python-3.3.2.amd64.msi
GDAL for python: GDAL-1.10.0.win-amd64-py3.3.‌exe from
http://www.lfd.uci.edu/~gohlke/pythonlibs/

My PATH contains a reference to both the GDAL folder and the Python folder.

When entering python and entering:

>>>from osgeo import gdal

I get the following kinds of information:

The procedure entry point
?GetDefaultRAT@GDALRasterBand@@UEAAPEAVGDALRasterAttributeTable@@XZ could not
be located in the dynamic link library gdal110.dll. (This is presented in a
Windows pop up).

ERROR 1: Can’t load requested DLL: ……\GDAL\gdalplugins\gdal_BAG.dll. 127: The
specified procedure could not be found. (This is presented at the command line).
ERROR 1: Can’t load requested DLL: ……\GDAL\gdalplugins\...
…
ERROR 1: Can’t load requested DLL: ……\GDAL\gdalplugins\gdal_netCDF.dll. 127:
The specified procedure could not be found.

The above path points (correctly) to my GDAL installation. I have no other GDAL
left overs in my PATH.

I have previously done this for GDAL 1.9.2 and python 3.3.0 and they worked
fine together – was I just too lucky then? Is there something I can do
differently to solve my GDAL incompatibilities? I would prefer not to compile
my self.

Regards

Casper

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL v.1.10 and Python 3.3.2 - incompatible?

2013-07-03 Thread CABO

Hi Christoph

Thank you for your answer. It works fine if I remove the other GDAL from the 
path, but it makes it very difficult to use Python with GDAL and the GDAL 
utilities in the same workflow.

Thanks for the clarification about "other GDAL builds".

I guess I was lucky the last time when I combined the two :)


Regards, Casper

-Original Message-
From: gdal-dev-boun...@lists.osgeo.org 
[mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Christoph Gohlke
Sent: 2. juli 2013 19:24
To: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] GDAL v.1.10 and Python 3.3.2 - incompatible?

As mentioned on the webpage, the GDAL-1.10.0.win-amd64-py3.3.‌exe installer 
includes all required files (Python package, DLLs, tools, and
data) and should not be used together with OSGeo4W or gdalwin32 (which implies 
also other GDAL builds). Mixing DLLs from different builds in PATH can not be 
expected to work. Does `from osgeo import gdal` work if after removing the GDAL 
folder from PATH?

Christoph


On 7/2/2013 2:59 AM, Casper Børgesen (CABO) wrote:
> Hi everyone.
>
> I’m trying to setup GDAL 1.10 and python 3.3.2 using the following binaries:
>
> GDAL:
> http://www.gisinternals.com/sdk/Download.aspx?file=release-1600-x64-gd
> al-mapserver\gdal-110-1600-x64-core.msi
> <http://www.gisinternals.com/sdk/Download.aspx?file=release-1600-x64-g
> dal-mapserver%5Cgdal-110-1600-x64-core.msi>
>
> Python: http://www.python.org/ftp/python/3.3.2/python-3.3.2.amd64.msi
>
> GDAL for python: GDAL-1.10.0.win-amd64-py3.3.‌exefrom
> http://www.lfd.uci.edu/~gohlke/pythonlibs/
> <http://www.lfd.uci.edu/%7Egohlke/pythonlibs/>
>
> My PATH contains a reference to both the GDAL folder and the Python folder.
>
> When entering python and entering:
>
>>>>from osgeo import gdal
>
> I get the following kinds of information:
>
> The procedure entry point
> ?GetDefaultRAT@GDALRasterBand@@UEAAPEAVGDALRasterAttributeTable@@XZ
> could not be located in the dynamic link library gdal110.dll. (This is 
> presented in a Windows pop up).
>
> ERROR 1: Can’t load requested DLL: ……\GDAL\gdalplugins\gdal_BAG.dll.
> 127: The specified procedure could not be found. (This is presented at 
> the command line).
>
> ERROR 1: Can’t load requested DLL: ……\GDAL\gdalplugins\...
>
> …
>
> ERROR 1: Can’t load requested DLL: ……\GDAL\gdalplugins\gdal_netCDF.dll.
> 127: The specified procedure could not be found.
>
> The above path points (correctly) to my GDAL installation. I have no 
> other GDAL left overs in my PATH.
>
> I have previously done this for GDAL 1.9.2 and python 3.3.0 and they 
> worked fine together – was I just too lucky then? Is there something I 
> can do differently to solve my GDAL incompatibilities? I would prefer 
> not to compile my self.
>
> Regards
>
> Casper
>
>
>
> ___
> 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 mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] GeoTIFF and LZWDecode (LZWEncode?) errors

2013-07-11 Thread CABO

Hi

When batch processing GeoTIFF files, I tend to get this problem a bit too often:

Warning 1: LZWDecode:LZWDecode: Strip 11 not terminated with EOI code
ERROR 1: LZWDecode:Not enough data at scanline 11 (short 30 bytes)
ERROR 1: TIFFReadEncodedStrip() failed.

band 1: IReadBlock failed at X offset 0, Y offset 11
ERROR 1: GetBlockRef failed at X block offset 0, Y block offset 11

The strip, scanline and offsets vary. It normally happens when I process from 
clients (computers) with the files located on servers (on local network), and I 
can reprocess a file again without getting the error, or possible an error with 
a different strip, scanline or offset. This special case is caused by 
gdaldem.exe and the error is reported by gdal_translate.exe using GDAL 1.9, but 
I have experienced this error using GDAL 1.9.2 and I think I saw it using GDAL 
1.10 also.

I have two issues here:

1.   Why the problem is happening to begin with?

2.   Why does the Warning and/or Error not trigger ERRORLEVEL 1?

The first bullet I think can be very difficult to debug, so I seek experiences 
here. The second bullet is really frustrating, because I have to look through 
all my clients looking for output similar to the message above - and then 
reprocess all crashed files again.

One solution I have seen somewhere is to not compressing the files, but this 
results in quite an increase in disk space usage - way too high for me.


Kind regards, Casper
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GeoTIFF and LZWDecode (LZWEncode?) errors