Re: [gdal-dev] Motions: Promote 1.11.5 RC 1, 2.0.3 RC2 and and 2.1.1 RC2for release

[Tamas Szekeres]

+1 for all

Tamas



Feladó: Even Rouault___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion: adopt RFC 66: OGR random layer read/write capabilities

[Tamas Szekeres]

+1

Tamas



2016-10-05 12:44 GMT+02:00 Even Rouault :

> Hi,
>
> I know that Howard has expressed some concerns regarding the potential
> confusion that this could add, but I'm not sure what better alternatives
> there
> would be to address the needs it tries to solve.
>
> So I move to adopt RFC 66: OGR random layer read/write capabilities
>
> https://trac.osgeo.org/gdal/wiki/rfc66_randomlayerreadwrite
>
> ---
>
> Starting with my +1
>
> Even
>
> --
> 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] Motion: Promote 2.1.3RC1 for release

[Tamas Szekeres]

+1

Tamas

2017-01-25 9:27 GMT+01:00 Even Rouault :

> Hi,
>
>
>
> Motion: GDAL/OGR 2.1.3RC1 is promoted to be the official 2.1.3 final
> release.
>
>
>
> ---
>
>
>
> +1 Even
>
>
>
> --
>
> Spatialys - Geospatial professional services
>
> http://www.spatialys.com
>
> ___
> 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] Need solution for C# setup, with error at OSGeo.OGR registration

[Tamas Szekeres]

Hi,

You probably have multiple dll dependencies availabe in the path. Try copying 
all the dependencies from the same package to the location where your excutable 
is running.

Best regards,

Tamas

Az iPhone-omról küldve

2017. aug. 1. dátummal, 17:08 időpontban C. Zeng  írta:

> ​Hello all,
> 
> I am trying to setup the GDAL in C#.NET 2015, with an error at the 
> registration of the Ogr. A previous post stated the exact same problem but 
> without a solution, I tried to reply in that post but failed,thus send this 
> email instead. 
> 
> That previous post described my problem very well:  
>> "I am using ogr_csharp.dll in my c# program. See the following code snippet: 
>> using OSGeo.OGR; 
>> namespace Test 
>> { 
>> public class Test 
>> { 
>> public Test() 
>> { 
>> ... 
>>   Ogr.RegisterAll(); 
>> }   
>> } 
>> } 
>> Then the following exception message was thrown out when the program is 
>> executed: 
>> {"The type initializer for 'OSGeo.OGR.OgrPINVOKE' threw an exception."}  
>>
>> System.Exception {System.TypeInitializationException} 
>> Does anyone know how to resolve this issue? "
> 
> Some more details for my case. My steps are: 
> - downloaded the stable or daily stable release (same error later) from here. 
> - added the "...\bin" and "...\bin\gdal\csharp" to Environment Variable, 
> setup a sample project, 
> - add the 4 "###sharp.dll" from csharp folder to project reference. 
> - import namespace:  using OSGeo.OGR; using OSGeo.OSR;  and add a simple line 
> "Ogr.RegisterAll(); " 
> 
> Then I can successfully build the project, but with the following error msg. 
> I tried all possible solutions by Google plus this forum such as this and 
> this. 
> test all the x64/x86 , debug/release, switches, no luck. 
> 
> Any comment is appreciated, thank you! 
> 
> Chui 
> 
> 
> 
> --error message -- 
> 
> Unhandled Exception: System.TypeInitializationException: The type initializer 
> fo 
> r 'OSGeo.OGR.OgrPINVOKE' threw an exception. ---> 
> System.TypeInitializationExcep 
> tion: The type initializer for 'SWIGExceptionHelper' threw an exception. ---> 
> Sy 
> stem.BadImageFormatException: An attempt was made to load a program with an 
> inco 
> rrect format. (Exception from HRESULT: 0x8007000B) 
>at 
> OSGeo.OGR.OgrPINVOKE.SWIGExceptionHelper.SWIGRegisterExceptionCallbacks_Og 
> r(ExceptionDelegate applicationDelegate, ExceptionDelegate 
> arithmeticDelegate, E 
> xceptionDelegate divideByZeroDelegate, ExceptionDelegate 
> indexOutOfRangeDelegate 
> , ExceptionDelegate invalidCastDelegate, ExceptionDelegate 
> invalidOperationDeleg 
> ate, ExceptionDelegate ioDelegate, ExceptionDelegate nullReferenceDelegate, 
> Exce 
> ptionDelegate outOfMemoryDelegate, ExceptionDelegate overflowDelegate, 
> Exception 
> Delegate systemExceptionDelegate) 
>at OSGeo.OGR.OgrPINVOKE.SWIGExceptionHelper..cctor() 
>--- End of inner exception stack trace --- 
>at OSGeo.OGR.OgrPINVOKE.SWIGExceptionHelper..ctor() 
>at OSGeo.OGR.OgrPINVOKE..cctor() 
>--- End of inner exception stack trace --- 
>at OSGeo.OGR.OgrPINVOKE.RegisterAll() 
>at OSGeo.OGR.Ogr.RegisterAll() 
>at TestProj.Main(String[] args) in 
> \user\Downloads\Workspace\TestProj\project.cs:line 47
> 
> and also the following log info: 
> 'TestProj.vshost.exe' (CLR v4.0.30319: TestProj.vshost.exe): Loaded 
> 'C:\WINDOWS\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll'.
>  Cannot find or open the PDB file. 
> 'TestProj.vshost.exe' (CLR v4.0.30319: TestProj.vshost.exe): Loaded 
> 'C:\WINDOWS\assembly\GAC_MSIL\Microsoft.VisualStudio.HostingProcess.Utilities\14.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.HostingProcess.Utilities.dll'.
>  Cannot find or open the PDB file. 
> 'TestProj.vshost.exe' (CLR v4.0.30319: TestProj.vshost.exe): Loaded 
> 'C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Windows.Forms\v4.0_4.0.0.0__b77a5c561934e089\System.Windows.Forms.dll'.
>  Cannot find or open the PDB file. 
> 'TestProj.vshost.exe' (CLR v4.0.30319: TestProj.vshost.exe): Loaded 
> 'C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System\v4.0_4.0.0.0__b77a5c561934e089\System.dll'.
>  Cannot find or open the PDB file. 
> 'TestProj.vshost.exe' (CLR v4.0.30319: TestProj.vshost.exe): Loaded 
> 'C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Drawing\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Drawing.dll'.
>  Cannot find or open the PDB file. 
> 'TestProj.vshost.exe' (CLR v4.0.30319: TestProj.vshost.exe): Loaded 
> 'C:\WINDOWS\assembly\GAC_MSIL\Microsoft.VisualStudio.HostingProcess.Utilities.Sync\14.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.HostingProcess.Utilities.Sync.dll'.
>  Cannot find or open the PDB file. 
> 'TestProj.vshost.exe' (CLR v4.0.30319: TestProj.vshost.exe): Loaded 
> 'C:\WINDOWS\assembly\GAC_MSIL\Microsoft.VisualStudio.Debugger.Runtime\14.0.0.0__b03f5f7f11d50a3a\Microsof

Re: [gdal-dev] Call for discussion on RFC68: C++11 compilation mode

[Tamas Szekeres]

Hi Even,

Yes, I'm planning to include msvc2015/2017 versions shortly.

Best regards,
Tamas

Sent from my iPhone

2017. aug. 14. dátummal, 19:02 időpontban Even Rouault 
 írta:

> Hi Tamas,
>  
> Unless I'm mistaken your gisinternals.com builds don't include MSVC 2015 
> currently. Right ? Do you have any plans to do so ? Currently the GDAL 
> AppVeyor target uses SDKSs from gisinternals to do builds with a number of 
> third-party libraries.
>  
> Even
>  
> >
> > This is a call for discussion on RFC68 to set C++11 to be the minimum C++
> > language version for GDAL trunk. I've drafted the RFC based on work by
> > Mateusz.
> >
> > https://trac.osgeo.org/gdal/wiki/rfc68_cplusplus11
> >
> > There was initial discussions back in January of this year:
> >
> > https://lists.osgeo.org/pipermail/gdal-dev/2017-January/thread.html#45786
> >
> > Cheers,
> > -kurt
> > Engineer at Google
>  
>  
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Call for discussion on RFC68: C++11 compilation mode

[Tamas Szekeres]

Hi Even,

The new SDK-s have now been added.

Best regards,

Tamas


2017-08-29 15:18 GMT+02:00 Tamas Szekeres :

> Hi Even,
>
> Yes, I'm planning to include msvc2015/2017 versions shortly.
>
> Best regards,
> Tamas
>
> Sent from my iPhone
>
> 2017. aug. 14. dátummal, 19:02 időpontban Even Rouault <
> even.roua...@spatialys.com> írta:
>
> > Hi Tamas,
> >
> > Unless I'm mistaken your gisinternals.com builds don't include MSVC
> 2015 currently. Right ? Do you have any plans to do so ? Currently the GDAL
> AppVeyor target uses SDKSs from gisinternals to do builds with a number of
> third-party libraries.
> >
> > Even
> >
> > >
> > > This is a call for discussion on RFC68 to set C++11 to be the minimum
> C++
> > > language version for GDAL trunk. I've drafted the RFC based on work by
> > > Mateusz.
> > >
> > > https://trac.osgeo.org/gdal/wiki/rfc68_cplusplus11
> > >
> > > There was initial discussions back in January of this year:
> > >
> > > https://lists.osgeo.org/pipermail/gdal-dev/2017-
> January/thread.html#45786
> > >
> > > Cheers,
> > > -kurt
> > > Engineer at Google
> >
> >
> > --
> > Spatialys - Geospatial professional services
> > http://www.spatialys.com
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] git(hub) migration ?

[Tamas Szekeres]

I would also prefer to go for #3 if possible, though I don't have enough
experience how to make it happen.

Best regards,

Tamas


2017-09-06 15:14 GMT+02:00 Even Rouault :

> Hi,
>
>
>
> I've heard a few voices speaking/asking/begging for a git/github
> migration. At some point we'll certainly have to do it, as SVN vs git is
> beginning to feel more and more like CVS vs SVN 15 years ago.
>
>
>
> I can see different options :
>
>
>
> 1) migrate to git, and remain within the OSGeo infrastructure. This is for
> example the case of GEOS which uses the Trac git plugin and the GOGS (or is
> gitea?) git hosting (https://git.osgeo.org/gogs/geos/geos.git).
> gogs/gitea tries to replicate most github functionalities, but feature
> parity is still not there (you cannot comment on a commit e.g). We could
> still offer github as a mirror, which would ease contributions a bit
> compared to the current git->svn situation, but the "Merge" button from
> github couldn't (shouldn't) be used.
>
>
>
> 2) migrate code to github, accept pull requests (PR) directly there.
> Tickets still managed in Trac. But then we have no automated link between
> Trac and github (unless there's a Trac plugin for that). A few other OSGeo
> projects are in a similar situation: QGIS with Redmine for tickets and
> github for PR&code, GeoServer with JIRA for tickets and github for PR&code.
> I've some experience with the QGIS situation: Redmine can include github
> commit references if the git commit message includes the ticket number.
> But, of course, the other way doesn't work: from github UI, the # link
> doesn't work (or would point to a unrelated PR with same number). So this
> is middly satisfactory, and a regression from our current situation.
>
>
>
> 3) migrate code and tickets to github. I guess this would match most
> (especially occasional) contributor wishes regarding the "social" aspect.
> What would be needed is Trac -> github ticket migration. Thomas Bonfort did
> it for MapServer at some point, but he lost the script if I remember well
> (I can see in https://stackoverflow.com/questions/6671584/how-to-
> export-trac-to-github-issues a number of possibilities listed). One issue
> also is we have numbers taken by existing github pull requests, so there
> would be collisions on import (we could decide either to sacrifice
> colliding Trac tickets, as there are really old, currently the colision
> appear for tickets older than 2003, or move them to an available github
> ticket number. Or to sacrifice existing PR, but there are a few pending
> ones)
>
> There's also the valid concern about being tied with github.com regarding
> tickets. Recently I found https://github.com/josegonzalez/python-github-
> backup
>
> which can backup code, issues, pull requests, etc.. using the github API.
>
> Quickly tested it on their own repo. Seems to work (**), although a bit
> slow ( requires 2 GET per issue / pull request to retrieve extra details
> that are not retrieved by the global request you showed above). It has an
> incremental mode though which should make it efficient.
>
>
>
> My synthetic view of the situation:
>
> 1) is a pure free sofware & free hosting approach. Relies on SAC being
> appropriately man and machine powered (same as with SVN / Trac currently)
>
> 2) mixed solution. we still have ownership on all our data (code &
> tickets). but the separation between a ticket system and code+PR isn't
> ideal from a usability point of view
>
> 3) offers probably the best contributor experience. We loose a bit of
> control, but a backup(*) strategy exists (at least for now). I'd tend to
> favor this approach.
>
>
>
> I'm not sure if the current git mirror shouldn't be re-done from scratch.
> Its main drawback is that svn tags are reported as git branches, instead of
> git tags. I probably mis-configured things when I initiated the mirror a
> few years ago. Not completely sure this is worth the effort though. We can
> probably live with those existing mis-created tags, and use proper git tags
> for the future.
>
>
>
> The release procedure / script would also have to be updated. Probably
> other things too.
>
>
>
> There's also the question of the Trac Wiki, although this one might be
> defered for a later stage.
>
>
>
> So this email is mostly to say I'm open to the idea, but I'd appreciate if
> someone else could take the lead on this. I'd be happy to help. A RFC to
> formalize the move would be needed.
>
>
>
> Even
>
>
>
> (*) Backup might not be the inappropriate term, since this implies that
> you can easily restore things. If github closes or requires (insane) fees
> for open source projects, those saved tickets will have to be re-injected
> in some to-be-defined alternative, but at least their content is readable
> (json)
>
>
>
> (**) steps:
>
> 1) pip install github-backup
>
> 2) in github UI, create a personnal access token, so as to be able to use
> authenticated requests to github API, to bypass the rate limit of
> unauthenticate

Re: [gdal-dev] Motion: Accept GDAL/OGR 1.8.1RC1 as final release

[Tamas Szekeres]

Frank,

I have found 2 issues related to the mssql spatial and the mapinfo tab
driver.

http://trac.osgeo.org/gdal/ticket/4149
http://trac.osgeo.org/gdal/ticket/4150

Committed the fix for each and it would be great to have these changes in
1.8.1

Best regards,

Tamas




2011/7/7 Frank Warmerdam 

> Folks,
>
> Motion: That we accept the GDAL/OGR 1.8.1RC1 package as the
> final GDAL/OGR 1.8.1 release.
>
> --
>
> PSC members, please vote after at least some sort of testing.
> Non-PSC members please let us know if you discover problems!
>
> --
>
> +1 Frank
>
> --
>
> ---+--
> I set the clouds in motion - turn up   | Frank Warmerdam,
> warmer...@pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush| Geospatial Programmer for Rent
> ___
> 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] Frank going to Google and it is not mentionned once on the list!

[Tamas Szekeres]

Congrats for the new job, Frank!

Best regards,

Tamas




2011/7/7 Frank Warmerdam 

> Sylvain,
>
> Consider it mentioned now!  I had my first day today (lots to take in).
>
> I discussed this on my blog at:
>
>  http://fwarmerdam.blogspot.com/2011/06/joining-google.html
>
> The short summary is that while I intend to remain active working on GDAL
> it won't be as much as before, and I won't be available for paid consulting
> on GDAL due to the nature of my US work visa.
>
> Best regards,
>
> On Wed, Jul 6, 2011 at 1:50 PM, s duclos  wrote:
> > A quick search for "frank warmerdam google" on Google return 53,200
> results
> >
> > The same search on Bing return 16,400 results
> > But then Bing tell us that "Related Search: .. Frank Sinatra, .. Frank
> Zappa, ..
> > Anna Frank"
> >
> > Some guys at Google are going to have a chuckle
> >
> > Congrat!
> >
> >
> > Sylvain.
> > ___
> > gdal-dev mailing list
> > gdal-dev@lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/gdal-dev
> >
>
>
>
> --
>
> ---+--
> I set the clouds in motion - turn up   | Frank Warmerdam,
> warmer...@pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush| Geospatial Programmer for Rent
> ___
> 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] GDAL for Python 3.2 on Windows 64bit

[Tamas Szekeres]

2011/7/8 Even Rouault 

>
> http://vbkto.dyndns.org/sdk/ proposes bindings for 2.6, 2.7 and 3.1.
> Perhaps
> Tamas would want to add support for 3.2 ?
>
>
How do we stand with the Python 3.2 support in GDAL? Do we still require to
patch the gererated interface files so as to compile the bindings
successfully?
I'm a bit hesitant to include a patching step as part of the build execution
sequence.


Best regards,

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

Re: [gdal-dev] GDAL for Python 3.2 on Windows 64bit

[Tamas Szekeres]

I'm just working on to include that in the builds at
http://www.gisinternals.com/sdk/

Unfortunately I always have to patch the python-distutils stuff from
versions to versions so as to make it work with all the supported
compilers...

Best regards,

Tamas


2011/7/9 Isaac Gerg 

> Do you guys know when 3.2 will be supported?  How do I build from 3.2
> currently using the patches you mentioned -- are there instructions
> anywhere?
>
> Thanks in advance,
> Isaac
>
>
> On Sat, Jul 9, 2011 at 8:28 AM, Even Rouault  > wrote:
>
>> Le samedi 09 juillet 2011 13:56:54, Tamas Szekeres a écrit :
>> > 2011/7/8 Even Rouault 
>> >
>> > > http://vbkto.dyndns.org/sdk/ proposes bindings for 2.6, 2.7 and 3.1.
>> > > Perhaps
>> > > Tamas would want to add support for 3.2 ?
>> >
>> > How do we stand with the Python 3.2 support in GDAL? Do we still require
>> to
>> > patch the gererated interface files so as to compile the bindings
>> > successfully?
>> > I'm a bit hesitant to include a patching step as part of the build
>> > execution sequence.
>>
>> I've just downloaded the latest swig version 2.0.4 and the good news is
>> that
>> it now generates binding files compatible with Python 3.2 (as well as with
>> previous Python versions). I also tested quickly with Java and Perl and
>> the
>> generated files are good enough to enable "make test" to run successfully.
>>
>> However, with CSharp, the generated cpp files have the following duplicate
>> declaration
>>
>>  static OsrPINVOKE() {
>>  }
>>
>>  static OsrPINVOKE() {
>>  }
>>
>> which causes the following error :
>>
>> mcs /debug:full /target:library /out:osr_csharp.dll osr/*.cs
>> AssemblyInfo.cs
>> osr/OsrPINVOKE.cs(192,10): error CS0111: A member
>> `OSGeo.OSR.OsrPINVOKE.OsrPINVOKE()' is already defined. Rename this member
>> or
>> use different parameter types
>> osr/OsrPINVOKE.cs(188,10): (Location of the symbol related to previous
>> error)
>>
>> whereas it is ok with swig 1.3.40
>>
>> I couldn't find a relevant ticket in their bug tracker about this
>> duplicate
>> PINVOKE.
>>
>>
>> >
>> >
>> > Best regards,
>> >
>> > Tamas
>>
>
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL for Python 3.2 on Windows 64bit

[Tamas Szekeres]

GDAL Python 3.2 packages has now been added to the builds at
http://www.gisinternals.com/sdk/

Best regards,

Tamas


2011/7/9 Isaac Gerg 

> This sounds great.  Thanks so much Tamas.
>
> Isaac
>
>
> On Sat, Jul 9, 2011 at 5:07 PM, Tamas Szekeres wrote:
>
>> I'm just working on to include that in the builds at
>> http://www.gisinternals.com/sdk/
>>
>> Unfortunately I always have to patch the python-distutils stuff from
>> versions to versions so as to make it work with all the supported
>> compilers...
>>
>> Best regards,
>>
>> Tamas
>>
>>
>>
>> 2011/7/9 Isaac Gerg 
>>
>>> Do you guys know when 3.2 will be supported?  How do I build from 3.2
>>> currently using the patches you mentioned -- are there instructions
>>> anywhere?
>>>
>>> Thanks in advance,
>>> Isaac
>>>
>>>
>>> On Sat, Jul 9, 2011 at 8:28 AM, Even Rouault <
>>> even.roua...@mines-paris.org> wrote:
>>>
>>>> Le samedi 09 juillet 2011 13:56:54, Tamas Szekeres a écrit :
>>>> > 2011/7/8 Even Rouault 
>>>> >
>>>> > > http://vbkto.dyndns.org/sdk/ proposes bindings for 2.6, 2.7 and
>>>> 3.1.
>>>> > > Perhaps
>>>> > > Tamas would want to add support for 3.2 ?
>>>> >
>>>> > How do we stand with the Python 3.2 support in GDAL? Do we still
>>>> require to
>>>> > patch the gererated interface files so as to compile the bindings
>>>> > successfully?
>>>> > I'm a bit hesitant to include a patching step as part of the build
>>>> > execution sequence.
>>>>
>>>> I've just downloaded the latest swig version 2.0.4 and the good news is
>>>> that
>>>> it now generates binding files compatible with Python 3.2 (as well as
>>>> with
>>>> previous Python versions). I also tested quickly with Java and Perl and
>>>> the
>>>> generated files are good enough to enable "make test" to run
>>>> successfully.
>>>>
>>>> However, with CSharp, the generated cpp files have the following
>>>> duplicate
>>>> declaration
>>>>
>>>>  static OsrPINVOKE() {
>>>>  }
>>>>
>>>>  static OsrPINVOKE() {
>>>>  }
>>>>
>>>> which causes the following error :
>>>>
>>>> mcs /debug:full /target:library /out:osr_csharp.dll osr/*.cs
>>>> AssemblyInfo.cs
>>>> osr/OsrPINVOKE.cs(192,10): error CS0111: A member
>>>> `OSGeo.OSR.OsrPINVOKE.OsrPINVOKE()' is already defined. Rename this
>>>> member or
>>>> use different parameter types
>>>> osr/OsrPINVOKE.cs(188,10): (Location of the symbol related to previous
>>>> error)
>>>>
>>>> whereas it is ok with swig 1.3.40
>>>>
>>>> I couldn't find a relevant ticket in their bug tracker about this
>>>> duplicate
>>>> PINVOKE.
>>>>
>>>>
>>>> >
>>>> >
>>>> > Best regards,
>>>> >
>>>> > Tamas
>>>>
>>>
>>>
>>
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] gdalnumeric problems with Python 3.2 Windows 7 64 bit

[Tamas Szekeres]

Isaac,

I've took a chance to install the numpy-amd64 packages from the site you
mentioned. If the things are going well the tomorrow builds will contain the
numpy enabled gdal win64 packages.

I should however mention that I have some negative experiences with the
numpy enabled GDAL (WIN64) packages since the GDAL python tests were
crashing with this option, when I was trying to include this this last time.
So in case if the tests are not working well, I must revert this addition
and remove numpy from the Win64 setup. (The Win32 GDALpackages already
contain numpy at http://www.gisinternals.com/sdk)

Best regards,

Tamas





2011/7/11 Isaac Gerg 

> Im not sure I understood your original message.  In any case, I have it
> working now though I used a different GDAL build than the one down by Tamas.
>
>
> I uninstalled Tamas' build (had to delete a few files in the site-packages
> directory) and then install the GDAL libs from here:
> http://www.lfd.uci.edu/~gohlke/pythonlibs/
> GDAL-1.8.1.win-amd64-py3.2.‌exe
>   [6.6 MB]  [Python 3.2]  [64 bit]  [Jul 08, 2011]
>
> My code now works!
>
> Isaac
>
> On Mon, Jul 11, 2011 at 2:47 PM, Even Rouault <
> even.roua...@mines-paris.org> wrote:
>
>> Le lundi 11 juillet 2011 20:40:56, Isaac Gerg a écrit :
>> > Hmmm.. I just downloaded numpy from here:
>> > http://www.lfd.uci.edu/~gohlke/pythonlibs/ the 64bit windows one
>> without
>> > MKL.
>> >
>> > I installed it successfully and then reran the code.  Same error.  Any
>> > ideas?
>>
>> Yes, as I said in my previous answer, you need numpy at your side, but
>> that's
>> not enough. The GDAL python bindings need to be rebuilt against a python
>> with
>> numpy installed. So some extra work would be needed on Tamas side.
>>
>
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion: Approve GDAL/OGR 1.8.1RC2 for release

[Tamas Szekeres]

+1

Tamas



2011/7/12 Frank Warmerdam 

> Motion: GDAL/OGR 1.8.1RC2 is approved as the official 1.8.1
> release.
>
> +1 Frank
>
> --
>
> ---+--
> I set the clouds in motion - turn up   | Frank Warmerdam,
> warmer...@pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush| Geospatial Software Developer
> ___
> 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] Re: Motion: Commit Access for Paul Ramsey

[Tamas Szekeres]

+1

Best regards,

Tamas




2011/7/20 Even Rouault 

> Motion: Extend GDAL/OGR Commit Access to Paul Ramsey
>
> ---
>
> Hi,
>
> Paul, who has been involved for many years in the developement of various
> OSGeo projects like PostGIS or MapServer, has recently contributed in the
> developement of the OGR FileGDB driver. I have applied on his behalf
> various
> patches he has submitted to Trac (*). His area of interest would also cover
> the OGR PG driver for which he has also contributed an enhancement
> recently.
>
> It would be convenient to give him direct commit access to subversion.
>
> Paul, could you reply to this message indicating your agreement to the
> guidelines listed in:
>
>http://trac.osgeo.org/gdal/wiki/rfc3_commiters
>
> I'll start voting with my support:
>
> +1
>
> Best regards,
>
> Even
>
> (*) See http://trac.osgeo.org/gdal/search?q=FGDB&noquickjump=1&ticket=on
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] .NET and OGR writing to stream

[Tamas Szekeres]

Maksim,

You can refer to the example
http://trac.osgeo.org/gdal/browser/trunk/gdal/swig/csharp/apps/GDALRead.csto
see how to read data into a byte array and then you can write this
array
directly to the memory stream.

Best regards,

Tamas



2011/7/31 Maksim Sestic 

>  Hi all,
>
> ** **
>
> Is there any example of OGR driver writing to memory stream (instead of
> file stream), in .NET?
>
> ** **
>
> Regards,
>
> Maksim Sestic
>
>
> __ Information from ESET NOD32 Antivirus, version of virus
> signature database 6338 (20110731) __
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.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] How to register ArcSDE driver

[Tamas Szekeres]

Hi,

Make sure to place the ogr_SDE.dll into the /gdalplugins subdirectory from
where your application is running. Alternatively you can set the
GDAL_DRIVER_PATH environment setting to point to the directory of the plugin
dll-s

Best regards,

Tamas



2011/8/9 L.M Tan 

> hi,
>
> I am interested in using *OGR *to read data from an ArcSDE (9.2-9.3)
> database. I have built ogr_SDE.dll,but i can not open the SDE database.
>
> This is the csharp code :
>
> Ogr.RegisterAll();
> Driver sdedr = Ogr.GetDriverByName("SDE");   //   sdedr =
> null
> /*
>  */
> /*  Open data source.
> */
> /*
>  */
> DataSource ds = Ogr.Open("SDE:192.168.1.123,5151,sde,sde,sde",
> 0); //   ds=null
>
> I want to know how to register ArcSDE driver.
>
> TIA for any advice you might give and have a great day!
> ___
> 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] New PHP bindings - php5-gdal

[Tamas Szekeres]

2011/8/9 Jean-François Gigand 

>
> I decided to write this library when I got limited at using OGR/PHP
> (segfault crash) and noticed the latter has not been maintained for
> years.
> After trying to compile the SWIG bindings with no success, I thought a
> good robust C++ code would be the best deal for providing OOP
> interfaces to PHP.
>
>

Hi Jean,

I just wanted to mention, there have been some efforts recently by Mike
Leahy to resurrect the php bindings, the corresponding ticket can be found
here:
http://trac.osgeo.org/gdal/ticket/3984

However I'm not sure about the current status of this work and how the
bindings work with the attached patches. Do you have experiences?

Best regards,

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

Re: [gdal-dev] The problem when using ReadRaster(C#) method

[Tamas Szekeres]

You should make sure about the actual representation of the raster image,
whether it represents the pixel as floats as you have used float arrays in
the code. The last 2 parameters are used to define the byte offset of the
pixels and lines in the image ( for more info see the
RasterIOdocumentation).

Further C# related samples can be found here:
http://trac.osgeo.org/gdal/browser/trunk/gdal/swig/csharp/apps/GDALRead.cs
http://trac.osgeo.org/gdal/browser/trunk/gdal/swig/csharp/apps/GDALReadDirect.cs

Best regards,

Tamas



2011/8/31 hitweiran 

> I want to read a multiband image(in format of .img) by using method
> ReadRaster, however, I encount some problems. I just can't understand why
> the data loaded to memory is wrong?
> the code is like this
>
> OSGeo.GDAL.Dataset dataSet =
> OSGeo.GDAL.Gdal.Open(@"G:\building.img",OSGeo.GDAL.Access.GA_ReadOnly);
> int width = dataSet.RasterXSize;
> int height = dataSet.RasterYSize;
> int Band_Numbers = dataSet.RasterCount;
> float [] buffer_first = new float [width * height];
> OSGeo.GDAL.Band One_Band = dataSet.GetRasterBand(1);
> One_Band.ReadRaster(0, 0, width, height,buffer_first, width, height, 0,0);
>
> However, the output is wrong!
> I watch the variable "buffer_first" in watch window, and discoverse that
> the
> data is quite terrible-some data is such as 2.818478E+21,5.065476E+32, or
> -6.131138E-11 and so on;
> So I suspect my datatype is mismatch to data in img file, or the last two
> arguments in ReadRaster is mistake, because I don't know the meaning of
> last
> two parameters.
> Thanks a lot for your answer!
>
> --
> View this message in context:
> http://osgeo-org.1803224.n2.nabble.com/The-problem-when-using-ReadRaster-C-method-tp6745826p6745826.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

Re: [gdal-dev] Motion: Commit Access for Etienne Tourigny

[Tamas Szekeres]

+1

Tamas




2011/9/2 Even Rouault 

> Motion: Extend GDAL/OGR Commit Access to Etienne Tourigny
> ---
>
> Hi,
>
> Kyle Shannon and I would like to propose Etienne Tourigny for commit access
> to
> GDAL subversion repository.
>
> Etienne has recently contributed in the developement of the netCDF driver.
> He
> has submitted many ideas for fixes and improvements in the driver ( see
> this
> thread http://lists.osgeo.org/pipermail/gdal-dev/2011-August/029865.html),
> that he has organized in this wiki page :
>
> http://trac.osgeo.org/gdal/wiki/NetCDF_Improvements
>
> He has also proposed various patches to tickets in Trac, or engaged
> discussion
> with their reporters :
>
> http://trac.osgeo.org/gdal/ticket/2129
> http://trac.osgeo.org/gdal/ticket/2893
> http://trac.osgeo.org/gdal/ticket/3957
>
> Etienne has graduated in Computer Science at Université de Montréal and
> Master's in Atmospheric Science at UQAM. He's currently working on his PhD
> in
> Meteorology at INPE/CPTEC/CCST in Brazil. His interest in GDAL has arisen
> because he's working with burned area and land cover maps at high (Landsat)
> and medium (MODIS) resolutions and he has a need for fixing and improving
> the
> driver so as to be able to produce files in netcdf format. He has also been
> involved in the CDO operators, and started a discussion with the devs on
> incorporating geotiff and full Proj.4 support. He has also submitted minor
> bug
> reports and enhancements for QGIS.
>
> Etienne, could you reply to this message indicating your agreement to the
> guidelines listed in:
>
>http://trac.osgeo.org/gdal/wiki/rfc3_commiters
>
> I'll start voting with my support:
>
> +1
>
> Best regards,
>
> Even
> ___
> 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] OGR SQL implicit conversions

[Tamas Szekeres]

Hi Devs,

We have some problems due to the recent changes in the SQL expression parser
which is related to the change in the implicit type conversion behaviour.

Formerly we could safely use the following statement:

select * from mytable where ogr_fid in ('1100','1101','1102')

If the data type of ogr_fid is an integer or float then the expression
evaluator has converted the string constants to numeric values implicitly.

As of 1.8 the parser reports an error due to the incompatible types in the
expression.

I've added a ticket #4259  related
to this problem including a patch to handle these string to numeric
conversions.

However I'm a bit uncertain whether some other conversions should also be
supported or not. Having a larger number of conversion rules we might
probably think about rewriting the current approach by using a more generic
implementation.

Any ideas?


Best regards,

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

[gdal-dev] OGR SQL expression parser overflow

[Tamas Szekeres]

Hi Devs,

I've run into a "memory exhausted" error in the OGR SQL parser when the
token count exceeds 200. This is related to the YYINITDEPTH setting in
swq_parser.cpp
Does anyone know how to enable the built in stack extension mechanism which
can automatically extend the stack size up to YYMAXDEPTH (1)?

Best regards,

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

[gdal-dev] Re: OGR SQL expression parser overflow

[Tamas Szekeres]

Just an update to this, I've created a ticket for this problem, and attached
a patch which seems to be working in my local set-up.
http://trac.osgeo.org/gdal/ticket/4262

Due to the lack of my knowledge about bison let me know if one have a more
appropriate solution to this problem.

Any objection to update such change in the stable branch?

Best regards,

Tamas



2011/9/25 Tamas Szekeres 

> Hi Devs,
>
> I've run into a "memory exhausted" error in the OGR SQL parser when the
> token count exceeds 200. This is related to the YYINITDEPTH setting in
> swq_parser.cpp
> Does anyone know how to enable the built in stack extension mechanism which
> can automatically extend the stack size up to YYMAXDEPTH (1)?
>
> Best regards,
>
> Tamas
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] OGR SQL implicit conversions

[Tamas Szekeres]

Hi Even,

Thanks for the valuable comments, I've modified the patch in accordance with
your suggestions.
http://trac.osgeo.org/gdal/attachment/ticket/4259/swq_op_general.cpp.patch

Let me know if you find something else that can be changed. I've just added
a warning if the conversion fails, but I'm not quite sure if we can easily
generate errors at this state of the processing.

Best regards,

Tamas



2011/9/23 Even Rouault 

> Le mercredi 21 septembre 2011 19:20:17, Tamas Szekeres a écrit :
> > Hi Devs,
> >
> > We have some problems due to the recent changes in the SQL expression
> > parser which is related to the change in the implicit type conversion
> > behaviour.
> >
> > Formerly we could safely use the following statement:
> >
> > select * from mytable where ogr_fid in ('1100','1101','1102')
> >
> > If the data type of ogr_fid is an integer or float then the expression
> > evaluator has converted the string constants to numeric values
> implicitly.
> >
> > As of 1.8 the parser reports an error due to the incompatible types in
> the
> > expression.
> >
> > I've added a ticket #4259 <http://trac.osgeo.org/gdal/ticket/4259>
> related
> > to this problem including a patch to handle these string to numeric
> > conversions.
>
> You didn't mention that the patch only applies to the comparison operators
> (
> >, >=, <, <=, =, <>, IN and BETWEEN ), which I think is an appropriate
> restriction. I was a bit skeptical at the beginning if it would also apply
> to
> +, - operators for example where it is not obvious in which way the
> conversion
> should be done.
>
> I have done a bit of testing with PostgreSQL, MySQL and SQLite and, and
> they
> indeed do the conversions you suggest.
>
> I've noticed that PostgreSQL issues an error when the conversion fails
> because
> the string constant isn't a numeric value.
>
> $ ogrinfo pg:dbname=autotest -sql "select * from poly where eas_id = 'a'"
> INFO: Open of `pg:dbname=autotest'
>  using driver `PostgreSQL' successful.
> ERROR 1: ERROR: invalid input syntax for double precision type : « a »
> LINE 1: ...cuteSQLCursor CURSOR for select * from poly where eas_id =
> 'a'...
>
> MySQL is much more silent about failed conversions however. With the MySQL
> OGR
> driver, nothing is emitted, but in the mysql console client, I could see a
> difference :
>
> mysql> select * from poly where eas_id = 'a';
> Empty set, 10 warnings (0.00 sec)
>
> sqlite is completely silent in similar situations.
>
> Personnaly, I think it would be appropriate for the OGR SQL engine to also
> emit an error/warning for failed conversions (or perhaps just a CPLDebug()
> if
> we feel that there's no reason to be too verbose in such situations), but
> obviously there doesn't seem to be a consensus on that among SQL vendors.
>
> I believe this can be detected with something like :
>
> val = strtod(pszVal, &endptr);
> if (endptr != pszVal + strlen(pszVal))
> {
>CPLError(...)
> }
>
>
> As far as the proposed patch is concerned, a bit of comment in the new
> function to explain shortly that it converts string constants to float
> constants when there is a mix of arguments of type numeric and string. In
> which case, integer constants will also be promoted to float. But that last
> part happens to be what SWQAutoPromoteIntegerToFloat() does already, so
> perhaps you could drop that part and just call
> SWQAutoConvertStringToNumeric()
> before SWQAutoPromoteIntegerToFloat(), so that
> SWQAutoConvertStringToNumeric() only does what its name suggests (perhaps
> renaming it to SWQAutoConvertStringToFloat() would be more consistant by
> the
> way) ? I have tested that quickly and it seems to work, but more extensive
> testing would be welcome.
>
> On a stylistic note, I've had a hard time figuring out the operator
> precedence
> when reading the test :
>
>if( (eArgType == SWQ_STRING
>&& (poSubNode->field_type == SWQ_INTEGER
>|| poSubNode->field_type == SWQ_FLOAT)) ||
>(eArgType == SWQ_INTEGER || eArgType == SWQ_FLOAT)
>&& (poSubNode->field_type == SWQ_STRING) )
>
> So, I'd suggest to move the ( parenthesis of the last line on the line
> before
> (please check that it was indeed your intent) :
>
>if( (eArgType == SWQ_STRING
>&& (poSubNode->field_type == SWQ_INTEGER
>|| poSubNode->field_type == SWQ_FLOAT)) ||
>((eArgType ==

[gdal-dev] Re: Question regarding GDAL .dll files for C#

[Tamas Szekeres]

Hi Zhenyu Lu,

You need not install the plugin dll-s if you don't require the corresponding
functionality.
With regards to the dependent dll-s, you can use the -dev packages from
http://www.gisinternals.com/sdk/ to compile your own versions using the
following steps:

1. Download the -dev package according to your compiler version.
2. Extract the SDK files in a specific directory (like C:\builds)
3. Check out the gdal sources into this directory.
4. Edit makefile and comment out the unwanted dependecies, like:

#GDAL_POSTGIS = YES

5. Open a Visual studio command prompt, and type:

nmake gdal GDAL_DIR=[your gdal directory]


Best regards,

Tamas



2011/10/3 Zhenyu Lu 

> Hi Tamas,
>
> Sorry for sending you email so late at night. I noticed that you're in
> charge of maintaining the GDAL binary and SDK packages. I would say that
> you've done a fatastic job so far for making so many GDAL binary and SDK
> packages. I've downloaded two .msi files which worked great. So I'm thinking
> that your knowledge might offer huge help for me.
> I would like to ask you several questions regarding the binary and SDK
> packages you've released.
> I used to use the .dll files of GDAL 1.5.2 before, which were compiled by
> myself using VS2005. Now I wrote a tool for students to use for their labs.
> I suddenly realized that all the computers of my uniersity have installed
> Windows 7 64bit operating system, and my previous compiled .dll files do not
> work anymore.
> So I downloaded the gdal-18-1400-x64-core.msi and installed it on
> my computer. Compared with the previous .dll files, the newly created .dll
> files has much larger size (maybe much more functions). I think it is mainly
> because I must include some other .dll files (hdf5dll, geos_c, libmysql,
> pdflib, and xerces-c_2_8.dll) to make it work. However, using my previously
> compiled .dll file, I only need to include the gdal1.5.dll itself. So my
> previous implementation has the file size of < 5 MB, but now the
> implementation grows to more than 20 MB which make it hard to distribute.
> Now I would like to ask is it possible for you to create .dll files or the
> installation file to only include the gdal18.dll file without the other
> plugin .dll files? Or is there a way for me to create such .dll files?
> Hopefully I have made my questions straightforward.
> Thank you so much if you could offer me some suggestions.
>
> -- Zhenyu Lu
> SUNY-ESF
>
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] deploying with GDAL libraries

[Tamas Szekeres]

2011/10/18 Pouliot, Christopher (DNR) 

>  1)  **What is the best way to incorporate PROJ.4?  Can I simply set
> the PROJ_LIB environment variable in my application to point to my PROJ.dll
> location?
>


In the default gdal build proj4 is loaded dynamically. Your responsibility
is to deploy proj.dll into a location available in the common Windows dll
search locations. (probably into the same directory of where the gdal dll
resides)
PROJ_LIB should point to the folder containing the epsg file etc.

**
>
> **2)  **What are the bare minimum files I need to incorporate into my
> application for deployment?  
>
> **
>
It depends on your compilation. You may use the Dependency Walker to make
sure which dlls your build depends on.


Best regards,

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

Re: [gdal-dev] ReadAsArray with Windows 7

[Tamas Szekeres]

2011/10/21 Frank Warmerdam 

> On Fri, Oct 21, 2011 at 6:34 AM, Discourse Maps 
> wrote:
> > Hi,
> >
> > I was wondering if the issue mentioned in a past thread has every been
> > addressed.
> >
> http://osgeo-org.1803224.n2.nabble.com/Gdal-Python-Win7-crash-with-ReadAsArray-td4398401.html
> >
> > I am having much the same issues with GDAL 1.6.1, Windows 7, and using
> > 'ReadAsArray'.  Python crashes almost every time.
> >
> > Any help is most appreciated.
>
> Jimmy,
>
> It looks like the folks running into the problem were all using
> Tamas' binaries.  Would you be willing to see if you can reproduce
> the problem with the OSGeo4W binaries?  If so, please file a ticket
> against GDAL with all the details and hopefully someone will be
> able to dig into it.
>
>

I think it wasn't mentioned which binaries have been used. By reading back
the thread above, it was said an old gdal distribution caused the issue
whereas the daily builds were working:


It appears that the official binaries for gdal 1.6 simply do not work on
Win7 x64 while the problem is already fixed in the cutting edge builds


Daily builds also do autotests including the use of ReadAsArray()
in numpy_rw.py  and it doesn't seem to be failing.
One issue I have in my mind is a crash with the x64 version of Python +
numpy+ GDAL (in autotests) therefore numpy hasn't been added in the x64
builds.

By all means if someone can prepare a ready to use test case to reproduce
this issue, I'll be happy to do a test with that.

Best regards,

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

Re: [gdal-dev] ReadAsArray with Windows 7

[Tamas Szekeres]

2011/10/21 Frank Warmerdam 
>
> If the problem with your script persists when using the OSGeo4W
> python environment then I should be able to reproduce it with a
> suitable bug report.  If it does not happen with OSGeo4W then
> the issue likely relates to Tamas's use of SWIG version for the
> python bindings, or possibly a mismatch between the version of
> Python he built for, and the version you are running.
>

Frank,

BTW: The daily builds at http://www.gisinternals.com/sdk/ always re-generate
the python bindings from the interface files. Is this something that makes
the python bindings more fragile compared to the pre-generated version of
the SWIG output hosted in GDAL SVN? However we may often find that the SWIG
output doesn't always updated when the interface is changing.

Best regards,

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

Re: [gdal-dev] Auto-selection of geometry column for MS SQL Server is not restrictive enough

[Tamas Szekeres]

Dan,

You can specify the geometry column name along with the table name in the
connection string, something like:

MSSQL:server=servername;database=dbname;tables=schemaname.tablename(geomcolumnname)

for more information see: http://www.gdal.org/ogr/drv_mssqlspatial.html

Best regards,

Tamas



2011/10/26 Dan Homerick 

> The current logic for detecting the geometry or geography column will
> accept a column of type "image" (a subset of binary string[1]) as the
> GeomColumn. Furthermore, the logic checks the column types
> sequentially, and will accept an "image" column as the GeomColumn,
> even if there is a "geometry" or "geography" later in the list of
> columns.
>
> I came across this by trying to do queries on a table which does not
> have any spatial data, but which does have column of type "image". The
> image column was incorrectly assumed to be a geometry column, which
> naturally led to errors. This was despite NOT using "OGRSQL" as the
> dialect.
>
> There doesn't appear to be any interface to specify which, if any,
> column should be used as the GeomColumn -- am I (hopefully!) just
> overlooking something?
>
> [1] http://msdn.microsoft.com/en-us/library/ms187752.aspx
>
> - Dan
> ___
> 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] Motion: Approve RFC 37: User context data in CPLErrorHandler callbacks

[Tamas Szekeres]

+1

Tamas



2011/10/26 Howard Butler 

> Folks,
>
> Motion: To approve RFC 37: User context data in CPLErrorHandler callbacks
>
> http://trac.osgeo.org/gdal/wiki/rfc37_cplerror_userdata
>
> Having responded to input and updated the document accordingly, I would
> like now formally move to adopt RFC 37.
>
> Howard___
> 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] Kakadu Jpeg2000 driver

[Tamas Szekeres]

It seems kakadu SDK has an extraordinary license which would call for to
compile this driver as a plugin. I have been asked to compile gdal against
this dependency but I'm hesitant to think I could technically distribute
the gdal binaries in such form without adding the related binaries from the
kakadu SDK.

+1 to modify the makefile to compile as a plugin

Best regards,

Tamas


2011/11/1 Even Rouault 

> Selon Livneh Yehiyam :
>
> > Hi
> > Is it possible to build the JP2KAK driver as a plugin?
>
> You didn't mention on which OS you want to build it, but I have had a look
> at
> both makefiles, and I don't see any existing support for building as a
> plugin.
> However, I don't foresee any obvious reason why you this would not doable,
> provided that you can tweak the makefile.
>
> >
> > Thanks
> > Yehiyam
> ___
> 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] Kakadu Jpeg2000 driver

[Tamas Szekeres]

This sounds like a driver specific problem. Do you have some test data to
reproduce this?

Best regards,

Tamas



2011/11/2 Livneh Yehiyam 

>   Hi
>
> I'm trying to use the Kakadu Jpeg2000 (JP2KAK) driver to read raster data.
> 
>
> I'm working on windows7 64 bit with gdal source version 1.8.1
>
> ** **
>
> I've compiled the Kakadu SDK version v6.0 (v6_0-00828N), and compiled Gdal
> with the driver enabled. I'm using the c# binding.
>
> ** **
>
> I can open the dataset, and everything looks ok (size, number of
> overviews, band count etc.).
>
> When I read data from one of the bands at the base resolution (lets say it
> is 512x512) I get the correct data.
>
> Band mainBand = dataset.GetRasterBand(1);
>
> mainBand.ReadRaster(0,0,512,512,buffer,512,512,DataType.GDT_Byte,4,2048);*
> ***
>
> ** **
>
> If I get one of the overview bands:
>
> Band overviewBand = mainBand.GetOverview(0);
>
> ** **
>
> And I try to read the entire band (lets say it is 256x256):
>
>
> overviewBand.ReadRaster(0,0,256,256,buffer,256,256,DataType.GDT_Byte,4,1024);
> 
>
> What I get in the buffer are the first 256x256 pixels of the mainBand.
>
> This is contrary to the behavior I'm used to get when reading GTiff files,
> or even JPEG2000 with the JP2ECW driver.
>
> ** **
>
> Is this behavior by design, or is there another way to achieve what I want.
> 
>
> ** **
>
> Thanks
>
> Yehiyam
>
> ** **
>   --
> * This message (including any attachments) issued by RAFAEL- ADVANCED
> DEFENSE SYSTEMS LTD. (hereinafter "RAFAEL") contains confidential
> information intended for a specific individual and purpose, may constitute
> information that is privileged or confidential or otherwise protected from
> disclosure. If you are not the intended recipient, you should contact us
> immediately and thereafter delete this message from your system. You are
> hereby notified that any disclosure, copying, dissemination, distribution
> or forwarding of this message, or the taking of any action based on it, is
> strictly prohibited. If you have received this e-mail in error, please
> notify us immediately by e-mail mailto:law...@rafael.co.il and completely
> delete or destroy any and all electronic or other copies of the original
> message and any attachments thereof. *
> --
>
> ___
> 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] NuGet package for GDAL C# bindings

[Tamas Szekeres]

Felix,

Not sure I clearly understand the benefit, though it may be due to my lack
of knowledge in NuGet.
Is this just another way how to deploy the compiled binaries or something
to be incorporated in the GDAL build process?

Best regards,

Tamas



2011/11/3 Felix Obermaier 

> Hello,
>
> are there any plans to supply a NuGet (www.nuget.org) package for the C#
> Bindings?
> Or is there an interest in me setting one up?
>
> Thanks
>
> Felix Obermaier
>
> --
> Ingenieurgruppe IVV GmbH & Co. KG
> Dipl.-Ing. Felix Obermaier
> Oppenhoffallee 171
> 52066 Aachen
>
> Telefon: +49 (241) 94691-39
> Telefax: +49 (241) 531622
> eMail: o...@ivv-aachen.de
> Internet: http://www.ivv-aachen.de
>
> Sitz der Gesellschaft: Aachen
> Amtsgericht Aachen HRA 6212
> GF: Bauassessor Dr.-Ing. Dieter Hölsken  IVV-Management GmbH  Amtsgericht
> Aachen HRB 12453
>
> ___
> 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] Motion: Authorize Islandwood Funding for Brian Case

[Tamas Szekeres]

+1

Tamas



2011/12/14 Frank Warmerdam 

> Motion: The GDAL PSC authorizes funding up to US$525 to pay entrance fees
> to the Islandwood Code Sprint for Brian Case.
>
> -
>
> Brian (aka winkey) has done lots of work in recent years on and with
> GDAL/OGR.  Most notably he has developed the libkml based OGR KML driver.
>
> Brian lives relatively near the Islandwood sprint and would arrange to get
> himself there and other ancillary costs.  We would just be paying the
> entrace fees (which also implicitly covers housing and food).  Information
> on the Islandwood Sprint (successor to the Toronto, NYC and Montreal
> sprints
> of recent years) is available at:
>
>  
> http://wiki.osgeo.org/wiki/**IslandWood_Code_Sprint_2012
>
> I'm afraid I haven't done a detailed financial review of GDAL/OGR project
> funds but I think we have in excess of $10K in reserve so this is a modest
> expenditure, and I think can serve the community building goals of the
> project
> well.  I think we should also be open to similar support for other
> substantial
> contributors to GDAL/OGR who don't have corporate travel support, who would
> like to attend the sprint, and who would be able to get themselves there.
> However, that is not explicitly covered by this motion.
>
> --
>
> I'll start with +1 Frank.
>
> PS. I'd love to make a new batch of GDAL project tshirts in the coming
> year if someone is up to organizing.
>
> Best regards,
> --
> --**-+**
> --
> I set the clouds in motion - turn up   | Frank Warmerdam,
> warmer...@pobox.com
> light and sound - activate the windows | http://pobox.com/warmerda
> and watch the world go round - Rush| Geospatial Software Developer
>
> __**_
> 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] Motion: Promote GDAL 1.9.0RC1 as GDAL 1.9.0 Final

[Tamas Szekeres]

GDAL autotests are looking good on Win64. Futher tests are welcome.

Best regards,

Tamas



2012/1/2 Etienne Tourigny 

> What is the status of Windows 32-bit and 64-bit ?  Have they been
> tested outside of Tamas' build bot?
>
> best wishes for 2012,
> Etienne
>
> On Sun, Jan 1, 2012 at 1:30 PM, Even Rouault
>  wrote:
> > Le dimanche 01 janvier 2012 02:38:00, Frank Warmerdam a écrit :
> >> Motion: To promote the GDAL/OGR 1.9.0RC1 release candidate as
> >> the final GDAL/OGR 1.9.0 release.
> >>
> >
> > I've managed to compile it (or the betas) on a variety of Unixes (CentOS
> 6.2,
> > Ubuntu 11.10, FreeBSD 8.0, NetBSD 5, OpenBSD 4.5, Solaris 10 and 11,
> Debian
> > Lenny on a big-endian host) and things seem to be in good shape.
> >
> > Has anyone tested on MacOS X ?
> >
> > The only regression I've found so far is in the Rasterlite driver (
> fixed in
> > http://trac.osgeo.org/gdal/ticket/4413 ). It was hidden by another
> problem in
> > the lastest libspatialite3.0.0 that was exhibited by the GDAL autotests.
> But I
> > don't think it justifies another RC per se.
> >
> > *Last minute* : I've just tested with CentOS 4.7 and CentOS 5.6 and I've
> found
> > a compilation problem with the sqlite driver (and in the GML driver when
> > sqlite3 support is available). Those 2 OS ship with sqlite 3.3.6, but we
> now
> > use various methods that weren't yet available. This is now fixed in
> trunk and
> > 1.9 branch (see http://trac.osgeo.org/gdal/ticket/4418 for details ).
> Not sure
> > if it is worth a RC2.
> >
> > Best regards,
> >
> > Even
> > ___
> > 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

Re: [gdal-dev] Loading data in MSSQL using ogr2ogr

[Tamas Szekeres]

Jeremy,

This seems to be a reasonable requirement. You should create a ticket for
this issue at:
http://trac.osgeo.org/gdal/newticket

Best regards,

Tamas



2012/1/12 Jeremy Palmer 

> Hi,
>
> I'm trying to load a CSV file into an existing MSSQL 2008 table using
> ogr2ogr:
>
> ogr2ogr -preserve_fid --debug on -append -skip
> failures -f MSSQLSpatial "MSSQL:server=\SQL_SERVER_2008;Integrated
> Security=true;database=;tables=test_csv_table_1(shape)" test1.vrt -nln
> test_csv
> _table_1 -s_srs epsg:4167
>
> The schema I've got is:
>
> CREATE TABLE [dbo].[test_csv_table_1](
>  [id] [int] NOT NULL,
>  [appellation] [text] NULL,
>  [affected_surveys] [text] NULL,
>  [parcel_intent] [text] NOT NULL,
>  [topology_type] [varchar](100) NOT NULL,
>  [statutory_actions] [text] NULL,
>  [land_district] [varchar](100) NOT NULL,
>  [titles] [text] NULL,
>  [survey_area] [numeric](20, 4) NULL,
>  [calc_area] [numeric](20, 4) NOT NULL,
>  [shape] [geometry] NULL,
> PRIMARY KEY CLUSTERED
> (
>  [id] ASC
> )WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY =
> OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
> ) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
>
>
> This currently fails. The reason being that the SQL generated by ogr2ogr
> is:
>
> SET IDENTITY_INSERT [dbo].[test_csv_table_1] ON;
>
> INSERT INTO [dbo].[test_csv_table_1] (shape, [id], [appellation],
> [affected_surveys], [parcel_intent], [topology_type], [statutory_actions],
> [land_district], [titles], [survey_area], [calc_area]) VALUES
> (geometry::STGeomFromText('POLYGON ((172.7825528
> -41.4211097333,172.78229796670001 -41.42127,172.7823694333
> -41.4212575333,172.7825528 -41.4211097333))',4167).MakeValid(), 3621203,
> 'Sec 8 SO 14436', 'SO 14436', 'DCDB', 'Primary', '[Referenced] Stopped Road
> to be Amalgamated [Tadmor Valley Road, Nelson] New Zealand Gazette 2009 p
> 186 Stopped and Amalgamated with Land in CT NL72/70', 'Nelson', '464435',
>50.,  38.3921);SET IDENTITY_INSERT
> [dbo].[test_csv_table_1] OFF;
>
> The issue can be resolved if I change my table schema so the id field is
> an identity column, but I don't want to do this.
>
> Is it possible to configure (or fix a bug) so the "SET IDENTITY_INSERT"
> SQL is not executed if the -preserve_fid option is used and the existing
> table does not have an identity field?
>
> Cheers,
> Jeremy
>
> #
>
> This message contains information, which is confidential and may be
> subject to legal privilege.
> If you are not the intended recipient, you must not peruse, use,
> disseminate, distribute or copy this message.
> If you have received this message in error, please notify us immediately
> (Phone 0800 665 463 or i...@linz.govt.nz) and destroy the original
> message.
> LINZ accepts no responsibility for changes to this email, or for any
> attachments, after its transmission from LINZ.
>
> Thank You.
>
>
> #
> ___
> 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] Motion: Commit Rights for Dmitry Barishnikov (aka bishop)

[Tamas Szekeres]

+1

Tamas


2012/1/24 Frank Warmerdam 

> Motion: GDAL/OGR Commit rights are extended to Dmitry Barishnikov
> /Дмитрий Барышников (userid: bishop).
>
> ---
>
> Folks,
>
> Dmitry has been providing patches for GDAL/OGR for several years
> now and has, in my opinion, demonstrated good understanding of
> the GDAL code base, and norms.  I think it would be helpful for him
> to have commit access.   You can see some of his past contributions at:
>
>  http://trac.osgeo.org/gdal/search?q=bishop
>
> Dmitry, could you publically reply to this message indicating your
> willingness to follow RFC3?
>
>  http://trac.osgeo.org/gdal/wiki/rfc3_commiters
>
> I'll start the voting with my support.
>
> +1 Frank
>
> --
>
> ---+--
> I set the clouds in motion - turn up   | Frank Warmerdam,
> warmer...@pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush| Geospatial Software Developer
> ___
> 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] HDF4 support for gdal 1.8

[Tamas Szekeres]

If you have a compiled version of the HDF4 libraries, you could probably
use the SDK from gisinternals  to include
that in the build (Makefile should be edited). I have never tried it by
myself, but I'll give it a try as my time permits.

Best regards,

Tamas



2012/2/1 singnage 

> I recently installed GDAL 1.8.1 from gisinternals.com/sdk on Windows 7, I
> was
> previously using 1.6 from FW Tools, this newer version does not support
> HDF4 but supports HDF5, can anyone point how can I install the HDF4 support
> for version 1.8.1.
>
> thanks
> NS
>
> --
> View this message in context:
> http://osgeo-org.1560.n6.nabble.com/HDF4-support-for-gdal-1-8-tp4356589p4356589.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

Re: [gdal-dev] Motion: Commit Rights for Robert Coup

[Tamas Szekeres]

+1

Tamas



2012/2/1 Even Rouault 

> Motion: GDAL/OGR Commit rights are extended to Robert Coup
> ---
>
> Folks,
>
> Robert Coup has been working over the last few weeks in submitting patches
> to
> improve and fix the new FileGDB driver. I have integrated them until now,
> but
> I think it would make the process smoother to give him commit access.
> Robert
> is testing with ESRI software such as ArcMap, which should help making sure
> output datasources produced by the FileGDB driver are interoperable with
> other
> software.
>
> Robert is a core committer on Mapnik and a committer on Dojo. He has also
> been
> a GSoC mentor for Mapnik & Dojo over the last few years
>
> Robert, could you publically reply to this message indicating your
> willingness to follow RFC3?
>
>  http://trac.osgeo.org/gdal/wiki/rfc3_commiters
>
> I'll start the voting with my support.
>
> +1 Even
> ___
> 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] Motion:Commit rights for David Zwarg

[Tamas Szekeres]

+1

Tamas



2012/3/13 Jorge Arevalo 

> Motion: GDAL/OGR Commit rights are extended to David Zwarg
>
> Hello,
>
> David Zwarg has been working over the last few weeks in submitting
> patches to improve and fix the PostGIS Raster driver. I have
> integrated them until now, but I think it would be easier to give him
> commit access.
>
> David is a committer to PostGIS, and have been working with the Raster
> developers for a couple years. He has commit access to an OpenLayers
> sandbox, and is the author of the ArcIMS Layer and ArcXML Format,
> which are now in the OpenLayers core. In addition, he has contributed
> patches to fix bugs in OpenLayers via trac. His company also develops
> some Open Source geoprocessing platforms, like GeoTrellis:
> https://github.com/azavea/geotrellis
>
> I think he's doing an excellent job with the PostGIS Raster driver.
> So, he has my complete support
>
> +1
>
> --
> Jorge Arevalo
> http://www.libregis.org
> ___
> 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] Mapinfo driver does not recognise certain datums properly

[Tamas Szekeres]

Hi Devs,

I have run into a problem when assigning a spatial reference to a mapinfo
file using ogr2ogr when using -a_srs "EPSG:28350".
The mapinfo driver doesn't seem to recognise the datum
(Geocentric_Datum_of_Australia_1994) and assigns WGS84 to the output file
which is a fairly inconvenient approach.

This problem is due to the incorrect entries in asDatumInfoList
(mitab_spatialref.cpp) since the entry for
Geocentric_Datum_of_Australia_1994 is missing, though it contains an entry
for the projection name GDA94 (and not for the datum name).

As far as I know the WKT datum names are vendor specific, therefore it's
not quite sufficient to use as a lookop key for the datum entries. But if
we use this approach even so, why don't we include the datum names from
gcs.csv for being compatible with the projections constructed by GDAL
itself?

Would that be reasonable to add multiple entries in asDatumInfoList or
placing this information in an external file?

Best regards,

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

[gdal-dev] Re: Mapinfo driver does not recognise certain datums properly

[Tamas Szekeres]

Hi Devs,

Got no answer, so I call up this thread for discussion again.

In fact the approach of identifying datums by the mapinfo driver (by using
the WKT name) is quite fragile causing problems for me and for others in
the past as well, for example with the issues described in:
http://trac.osgeo.org/gdal/ticket/481
http://trac.osgeo.org/gdal/ticket/3187

In 3187 the problem was attempted to be solved by extending the lookup
table by using multiple entries for the same datum having different names.
However this approach is quite insufficient since there's no official list
of the valid WKT datum names (which may also be vendor specific) and the
datum names are also altered by gdal ie. by replacing spaces with
underscores.

The 
patch<http://trac.osgeo.org/gdal/attachment/ticket/481/gdal-mitab-datum-2.patch>attached
to
#481 <http://trac.osgeo.org/gdal/ticket/481> looks more compelling to me as
it seems more trivial to identify the datums by EPSG code (where exists)
and not only by the datum name.

Any objections to apply such change in gdal (mitab) at last?

Best regards,

Tamas




2012/3/15 Tamas Szekeres 

> Hi Devs,
>
> I have run into a problem when assigning a spatial reference to a mapinfo
> file using ogr2ogr when using -a_srs "EPSG:28350".
> The mapinfo driver doesn't seem to recognise the datum
> (Geocentric_Datum_of_Australia_1994) and assigns WGS84 to the output file
> which is a fairly inconvenient approach.
>
> This problem is due to the incorrect entries in asDatumInfoList
> (mitab_spatialref.cpp) since the entry for
> Geocentric_Datum_of_Australia_1994 is missing, though it contains an entry
> for the projection name GDA94 (and not for the datum name).
>
> As far as I know the WKT datum names are vendor specific, therefore it's
> not quite sufficient to use as a lookop key for the datum entries. But if
> we use this approach even so, why don't we include the datum names from
> gcs.csv for being compatible with the projections constructed by GDAL
> itself?
>
> Would that be reasonable to add multiple entries in asDatumInfoList or
> placing this information in an external file?
>
> Best regards,
>
> Tamas
>
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Issue with SetConfigOption

[Tamas Szekeres]

What is the exception message specifically?

Best regards,

Tamas


2012/3/19 Pouliot, Christopher (DNR) 

> Hello,
>
> The App I'm using GDAL in is a C# (Visual Studio 2010, .NET 4.0)
> executable and is distributed to a couple thousand people.  For 95% of
> those people it is running great.  For the other 5% we're having trouble
> with the GDAL piece.  The error we get:  "The type initialize for
> 'OSGEO.GDAL.GdalPINVOKE' threw an exception"
>
> I've narrowed it down and it occurs the very first command I try using
> GDAL:
>
> OSGeo.GDAL.Gdal.SetConfigOption("GDAL_DATA", GDAL_DATA);
>
> I've read in previous threads that it may be related to needing the proper
> Microsoft Visual C++ Redistributables installed but we've got machines that
> have 2005, 2008, and 2010 redistributables installed and still no luck.
> I've also included the msvcp100.dll and msvcr100.dll files in my install
> package.
>
> I think we have the problem narrowed down to older machines running XP or
> Vista.  Beyond that I'm not sure.
>
> Does anyone know of other dependencies I should be trying?
>
> Thanks,
>
> Chris
>
> Chris Pouliot
> GIS Application Developer
> Minnesota Department of Natural Resources
> christopher.poul...@state.mn.us
> (651) 259-5491
>
>
> ___
> 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] Motion: Contract Chaitanya as GDAL Maintainer

[Tamas Szekeres]

+1

Tamas

2012/3/22 Frank Warmerdam 

> Motion: Frank Warmerdam is authorized to negotiate a paid maintainer
> contract with Chaitanya Kumar CH for up to $5200 USD at $13USD/hr
> over five months, and would be acting as supervisor, operating under
> the terms of RFC 9 (GDAL Paid Maintainer Guidelines).
>
> ---
>
> PSC Members,
>
> Chaitanya has indicated he is available again to do GDAL maintenance
> and I think it would be advantageous to have his support.  He is a solid
> developer, and has continued to be active in the GDAL community
> since his last work as GDAL maintainer.
>
> In addition to general bug fixing I am also hoping to have him do
> some work on packaging of GDAL and dependencies for things like
> OSGeo4W, and DebianGIS/UbuntuGIS/LiveDVD.
>
> I'll start things by voting:
>
> +1 Frank
>
> --
>
> ---+--
> I set the clouds in motion - turn up   | Frank Warmerdam,
> warmer...@pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush| Geospatial Software Developer
> ___
> 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] OSR .NET bindings

[Tamas Szekeres]

Maksim,

As far as I remember only the MSVC2010 builds compile for .NET 4.0. All
compilers use the default setting in this regard.

Best regards,

Tamas


2011/3/27 Maksim Sestic 

>  Hi all,
>
> ** **
>
> Am I missing something, or OSR managed binandings for GDAL 1.9.0 target
> .NET 4.0? Is there any specific reason for that, may I change this to
> target .NET 2.0?
>
> ** **
>
> Regards,
>
> Maksim Sestic
>
> ** **
>
>
> __ Information from ESET NOD32 Antivirus, version of virus
> signature database 7001 (20120326) __
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.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] MSSQL Spatial and 3D issue

[Tamas Szekeres]

Nicolas ,

Interesting problem, I'll take a look at it. Would you create a ticket for
this issue?

Best regards,

Tamas


2012/4/18 Nicolas Garel 

> Hi,
>
> ** **
>
> I’m relaunching the following thread:
>
> http://lists.osgeo.org/pipermail/gdal-dev/2011-June/029034.html
>
> This time with GDAL 1.9 and the problem remains.
>
> ** **
>
> Further explanation of what I’m trying to achieve:
>
> ** **
>
> I would like to write and read 3d spatial data. 
>
> ** **
>
> I have a 3d point(*-1092.7172471465196* *122.9009469897652* *
> -150.11442565917974)* and 3d line (-1363.889169860787 -5.255646621772087
> -150.1144256591798,-1109.9664261063763 142.60863989620026
> -17.396886979865542)
>
> I’ve have the passed the DIM=3D parameter when creating the layer and made
> sure that the parameter is being read properly into gdal.
>
> ** **
>
> It seems that writing the LINESTRING into the spatial database is correct
> because I’ve been debugging OGRMSSQLSpatialTableLayer::CreateFeature and
> the SQL statement seems alright for the line:
>
> INSERT INTO [dbo].[test01] (ogr_geometry) VALUES
> (geometry::STGeomFromText('LINESTRING *(-1363.889169860787
> -5.255646621772087 -150.1144256591798,-1109.9664261063763
> 142.60863989620026 -17.396886979865542*)',0)
>
> ** **
>
> Now if I want to read the data back *the Z component seems to be mixed up
> with other components of other points*. Here is the output of ogrinfo
> when reading 
>
> ** **
>
> >ogrinfo -al
> "MSSQL:server=mm00786\mm00786;database=Spatial;tables=dbo.test01;trusted_connection=yes"
> 
>
> ** **
>
> INFO: Open of
> `MSSQL:server=mm00786\mm00786;database=Spatial;tables=dbo.test01;trusted_connection=yes'
> 
>
>   using driver `MSSQLSpatial' successful.
>
> ** **
>
> Layer name: test01
>
> Geometry: Unknown (any)
>
> Feature Count: 2
>
> Extent: (-1363.889170, -150.114426) - (142.608640, 122.900947)
>
> Layer SRS WKT:
>
> (unknown)
>
> FID Column = ogr_fid
>
> Geometry Column = ogr_geometry
>
> OGRFeature(test01):1
>
>   POINT (-1092.7172471465196 122.9009469897652 -150.11442565917974)
>
> ** **
>
> OGRFeature(test01):2
>
>   LINESTRING *(-1363.889169860787 -5.255646621772087
> -1109.9664261063763,142.60863989620026 -150.1144256591798
> -17.396886979865542)*
>
> ** **
>
> Coordinates of the lines are WRONG. Check above with the example given
> above. 
>
> ** **
>
> However IF I specify a different geometry format other than native the X
> and Y coordinates are read properly but Z is omitted. See below ogrinfo
> ouput:
>
> ** **
>
> >ogrinfo -al
> "MSSQL:server=mm00786\mm00786;database=Spatial;tables=dbo.test01;trusted_connection=yes;
> *GeometryFormat=wkt;"*
>
> INFO: Open of
> `MSSQL:server=mm00786\mm00786;database=Spatial;tables=dbo.test01;trusted_connection=yes;GeometryFormat=wkt;'
> 
>
>   using driver `MSSQLSpatial' successful.
>
> ** **
>
> Layer name: test01
>
> Geometry: Unknown (any)
>
> Feature Count: 2
>
> Extent: (-1363.889170, -5.255647) - (-1092.717247, 142.608640)
>
> Layer SRS WKT:
>
> (unknown)
>
> FID Column = ogr_fid
>
> Geometry Column = ogr_geometry
>
> OGRFeature(test01):1
>
>   POINT (-1092.7172471465196 122.9009469897652)
>
> ** **
>
> OGRFeature(test01):2
>
>   LINESTRING *(-1363.889169860787 -5.255646621772087,-1109.9664261063763
> 142.60863989620026*)
>
> ** **
>
> Can you *please* tell me if the problem is from the writing or reading of
> GDAL or maybe I’m simply missing some information during writing or
> reading?!
>
> ** **
>
> Please reply to me. 
>
> ** **
>
> *Nicolas Garel **|* Junior Software Engineer
>
> *M*icromine Product
> *Email **|** *nga...@micromine.com
>
> ** **
>
> http://www.micromine.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] Propose Chen Zhen as committer

[Tamas Szekeres]

+1

Tamas


2012/4/29 Tyler Mitchell 

> Chen Zhen (zhenchen17) has been instrumental at tweaking our Ingres driver
> in OGR
> and he hopes for further contributions in the future (backporting and
> other improvements).
>
> At Frank's suggestion I'm proposing that Chen is set up to do commits to
> his area of focus directly.  Having him with commit access will really
> help streamline support and improvements over the longer term.
>
> I've sent him the reference to the RFC for committers guidelines and
> requirements and
> he is interested.
>
> Thanks,
> Tyler
>
> *Tyler Mitchell***
> Engineering Director
> Actian Corporation
> *tyler.mitch...@actian.com
> *
> MOBILE 250-303-1831
> SKYPE spatialguru
> www.actian.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] Motion: Promote GDAL 1.9.1RC2 to Final Release

[Tamas Szekeres]

+1

Tamas



2012/5/17 Frank Warmerdam 

> Motion: The GDAL/OGR 1.9.1RC2 release candidate is hearby
> declared the final GDAL/OGR 1.9.1 release.
>
> --
>
> +1 Frank
>
> --
>
> ---+--
> I set the clouds in motion - turn up   | Frank Warmerdam,
> warmer...@pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush| Geospatial Software Developer
> ___
> 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] GDAL alpha channels

[Tamas Szekeres]

I have added a ticked for such an issue long ago, but I don't remember
what would be the expected solution.
http://trac.osgeo.org/gdal/ticket/2279

There should be an external config option to instruct the driver which
representation should be used.

Best regards,

Tamas



2012/5/29 Craig Bruce :
> I have run into a problem using GDAL to read TIFF images with a alpha
> channels.  GDAL returns the source TIFF sample values verbatim regardless
> of whether the alpha channel is associated (pre-multiplied) or unassociated
> within the TIFF image samples.  (In each alpha model, the same pixel
> value with the same alpha value will have different sample values.)
>
> GDAL does not appear to enforce a specific alpha model in its interface
> (pre-multiplied or non-pre-multiplied) and does not appear to offer any
> indication of which is currently being used.  This creates a dead end as
> far as the GDAL interface goes.  My system and most image formats (e.g.,
> PNG) use the non-pre-multiplied alpha model.  TIFF can use either.
>
> What is a user supposed to do about this?
>
> --+--+--
> Dr. Craig S. Bruce        | Ph 819-771-8303 x205 |             CubeWerx Inc.
> Senior Software Developer |   Fax 819-771-8388   |  Gatineau, Québec, Canada
> csbr...@cubewerx.com      |  http://csbruce.com/ |  http://www.cubewerx.com/
> --+--+--
>     "How many legs does a dog have if you call the tail a leg?  Four.
>      Calling a tail a leg doesn't make it a leg." -- Abraham Lincoln
> ___
> 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] .NET and OGR writing to stream

[Tamas Szekeres]

VSIF* functions are not properly mapped to the C# bindings, VSIFReadL
has python specific implementation only, as far as I see.
I'm not sure whether this API should officially be published or not,
since I don't remember about an RFC or a ticket about the expected
requirements and type mapping suggestions (README.typemaps) or
examples.

Best regards,

Tamas



2012/5/29 Geoff Burns :
> Just reading through this thread about GDAL, C# and memory streams as
> I have a similar problem.
>
> The thread seemed to end on a positive note with Maksim Sestic and
> Even Rouault seeming to reach a conclusion.
>
> However when I started using the API's Maksim & Even where discussing
> I found that Gdal.VSIFWriteL took a string instead of byte[] and
> Gdal.VSIFReadL did not seem to exist.
>
> Tamas's suggestion of reading data into a byte array will not work for
> me as I would have to write the GeoTiff data to disk in reorder to
> read it into the byte array in order to manipulate it in memory which
> seems wasteful.
>
> I reached an impasse.
>
> Surely other people in the .NET world want use GDAL without hitting
> the disk whenever they want to generate or transform data.
>
> Does anyone have any experience in getting the csharp GDAL API's to
> talk to memory instead of disk?
>
> Regards,
> Geoff
>
> -Original Message-
>> 2011/8/03 Maksim Sestic
>>
> Hi Even,
>
> That's exactly what I was looking for. Yes, Gdal.VSIF* managed bindings are
> there. Alas, I've been looking for them under Ogr methods :-)
>
> Regards,
> Maksim Sestic
>
>
> -Original Message-
> From: Even Rouault
> Subject: RE: [gdal-dev] .NET and OGR writing to stream
>
>
>> Hi Tamas,
>>
>>
>>
>> I don't know how to apply the same principle onto OGR drivers (not GDAL).
>> I'm trying to create GML structure in memory using OGR driver, then handle
>> resulting XML string further. Don't want to write dataset to a file, then
>> read the file back to a string.
>
> With the OGR GML driver, you can write to /vsimem/some.gml for example. And
> then
> you should be able to read that in-memory file with gdal.VSIFOpenL() and
> read
> its content with gdal.VSIFReadL(). However I'm not sure that the C# bindings
> have been updated to support those VSIF*L functions.
>
> There are examples of you to use those API in Python there :
> http://trac.osgeo.org/gdal/browser/trunk/autotest/gcore/rfc30.py .
>
> The C# version should be close (provided that the bindings exist for it of
> course)
>
>>
>>
>>
>> Regards,
>>
>> Maksim Sestic
>>
>>
>>
>>   _
>>
>> From: Tamas Szekeres
>> Sent: Monday, August 01, 2011 13:05
>> To: Maksim Sestic
>> Subject: Re: [gdal-dev] .NET and OGR writing to stream
>>
>>
>>
>> Maksim,
>>
>> You can refer to the example
>> http://trac.osgeo.org/gdal/browser/trunk/gdal/swig/csharp/apps/GDALRead.cs
>> to see how to read data into a byte array and then you can write this
> array
>
>> directly to the memory stream.
>>
>> Best regards,
>>
>> Tamas
>>
>>
>>
>>
>> 2011/7/31 Maksim Sestic
>>
>> Hi all,
>>
>>
>>
>> Is there any example of OGR driver writing to memory stream (instead of
> file
>
>> stream), in .NET?
>>
>>
> ___
> 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] Motion to adopt the RFC 39

[Tamas Szekeres]

+1

Tamas


2012/6/27 Ari Jolma 

> Dear GDAL PSC,
>
> Some time ago I and Even spent some time to work on a patch which would
> initially implement the RFC OGR Layer Algebra. The RFC proposes new API for
> GDAL 2.0. The RFC is at http://trac.osgeo.org/gdal/**
> wiki/rfc39_ogr_layer_algebra
>
> We believe the RFC and associated patch is now ready for approval.
>
> I will now rise the status of the RFC from development to proposed and
> motion to adopt it.
>
> Best regards,
>
> Ari Jolma
>
> __**_
> 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] Ogr to access MSSQL DB

[Tamas Szekeres]

Benjamin,

What is the content of the geometry_columns metadata table in your database?

Best regards,

Tamas



2012/7/11 Benjamin 

> Hi, I try to connect my application to a DB with the framework Ogr (with
> C# warper). When I write folloing code, Ogr methods view the DB but can't
> read it. [code] Ogr.RegisterAll(); const string connectionString =
> @"Server=SERVEUR_NAME;Database=DATABASE_NAME;trusted_connection=yes";
> DataSource pnn3 = Ogr.Open("MSSQL:" + connectionString, 0); if (pnn3 ==
> null) throw new IOException("Creation of output file failed.");
> Console.WriteLine("pnn3.Name\t=" + pnn3.name);
> Console.WriteLine("pnn3.GetLayerCount()\t= " + pnn3.GetLayerCount());
> [/code] It display : [quote]
> Server=SERVEUR_NAME;Database=DATABASE_NAME;trusted_connection=yes 0
> [/quote] I know my DB is view because if I switch SERVEUR_NAME and/or
> DATABASE_NAME by an other name the exception is throwed On the other hand
> driver don't see my layers (it displays 0, and my db has near to 30
> layers). If someone have already connected to db MSSQL, can him suggests me
> an example of code (in C or C++ it is also great, it may help me) ? Notes:
> I use gdal-1.9.0 (with MSSQL Driver) link usefull : MSSQLSpatial -
> Microsoft SQL Server Spatial 
> DatabaseBest regards, Benjamin.
> --
> View this message in context: [gdal-dev] Ogr to access MSSQL 
> DB
> Sent from the GDAL - Dev mailing list 
> archiveat 
> 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

Re: [gdal-dev] Ogr to access MSSQL DB

[Tamas Szekeres]

It is required with the current ogr driver, however we could implement some
support to eliminate. This table is anyway included in the simple features
specification for databases standard.
If you create the layers by using ogr (ie. by using ogr2ogr command line
tool) the metadata tables are also created if necessary.

Best regards,

Tamas



2012/7/11 Benjamin 

> Is the geometry_columns table mandatory ?
> Because I have not such table.
>
> This table is not in the spatial standard, isn't it ?
> Ogr need to acces it ?
>
> If yes, I think I will have to create it.
>
> Thx for the clue,
> Benjamin.
>
> --
> View this message in context:
> http://osgeo-org.1560.n6.nabble.com/gdal-dev-Ogr-to-access-MSSQL-DB-tp4987592p4987674.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] New OGR driver: Imageset

[Tamas Szekeres]

Hi All,

We're thinking about implementing a new OGR driver which would represent a
set of images as a vector data source. The images are taken from any GPS
compatible mobile device, and each picture would be represented as a point
feature, the positions would be extracted from the exif information. The
file name and path would be provided as an attribute for each feature. This
data source could then be used by higher level apps to provide symbols at
the picture locations in the map and display the picture when the feature
is selected. The driver would definitely use GDAL to extract information
about the provided images.

I'm not sure whether we already have some kind of alternative solution to
this, let me know if you know about any. Further ideas about this topic
would also be helpful.

Best regards,

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

Re: [gdal-dev] New OGR driver: Imageset

[Tamas Szekeres]

Hi Andreas,

Yes I wanted to expose further information, too. It could probably be user
configurable. The driver would be read only, the EXIF would be extracted by
using the corresponding GDAL drivers.
The site you refer to is very interesting,. This is something that we'd
like to achieve. It is also possible to render the symbols as the image
thumbnails by using the image file path attribute in the mapping
applications.

Best regards,

Tamas



2012/7/23 Andreas Neumann 

> Hi Tamas,
>
> That would be interesting. So the user could specify a folder with images
> and GDAL would create an OGR layer that would expose the photo location?
> The OGR feature would have certain EXIF data exposed as attributes?
>
> If you work on this, could you also expose other EXIF data, such as the
> viewpoint coordinates, the image direction, the FOV or focal length, the
> sensor size, etc. - this information could be used to create a field of
> view angle of the picture.
>
> You can try this at 
> http://www.geofoto.ch/**geophotomap/index.svg<http://www.geofoto.ch/geophotomap/index.svg>where
>  you can click on a picture standpoint and the browser will display an
> angle where the picture is looking at.
>
> I'd be interested in such a provider, as it would open a lot of
> possibilities to display photo information in various applications.
>
> Are you aware of EXIFTOOL - the perl-script that allows getting and
> setting image metadata, such as EXIF, IPTC, XMP, etc.? See
> http://www.sno.phy.queensu.ca/**~phil/exiftool/<http://www.sno.phy.queensu.ca/~phil/exiftool/>-
>  it is sort of the Swiss Army Knife of photo metadata and one of the fewer
> apps that can also set metadata - not just read.
>
> Andreas
>
>
> On Mon, 23 Jul 2012 09:51:14 +0200, Tamas Szekeres wrote:
>
>> Hi All,
>>
>> We're thinking about implementing a new OGR driver which would
>> represent a set of images as a vector data source. The images are
>> taken from any GPS compatible mobile device, and each picture would be
>> represented as a point feature, the positions would be extracted from
>> the exif information. The file name and path would be provided as an
>> attribute for each feature. This data source could then be used by
>> higher level apps to provide symbols at the picture locations in the
>> map and display the picture when the feature is selected. The driver
>> would definitely use GDAL to extract information about the provided
>> images.
>>
>> I'm not sure whether we already have some kind of alternative solution
>> to this, let me know if you know about any. Further ideas about this
>> topic would also be helpful.
>>
>> Best regards,
>>
>> Tamas
>>
>
> --
> --
> Andreas Neumann
> Böschacherstrasse 10A
> 8624 Grüt (Gossau ZH)
> Switzerland
> __**_
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/**mailman/listinfo/gdal-dev<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] New OGR driver: Imageset

[Tamas Szekeres]

Hi Even,

I just want to use the directory name to define the connection to the
images, we could also provide to scan the files in subdirectories if
needed. I would prefer to have a new driver not just an offline tool for
creating OGR datasets, in this case many existing applications (like
MapServer) would be capable to utilize this feature.
I could imagine a driver configuration file to specify which driver should
be used for a particular image format and where the specific information is
located, I don't require to harmonize the metadata structure at this time.
We should probably allow mixing jpegs and tiffs in the same directory, but
the configuration should specify how the similar attributes are provided by
each (sub)driver.

Best regards,

Tamas



2012/7/23 Even Rouault 

> Le lundi 23 juillet 2012 09:51:14, Tamas Szekeres a écrit :
> > Hi All,
> >
> > We're thinking about implementing a new OGR driver which would represent
> a
> > set of images as a vector data source. The images are taken from any GPS
> > compatible mobile device, and each picture would be represented as a
> point
> > feature, the positions would be extracted from the exif information. The
> > file name and path would be provided as an attribute for each feature.
> This
> > data source could then be used by higher level apps to provide symbols at
> > the picture locations in the map and display the picture when the feature
> > is selected. The driver would definitely use GDAL to extract information
> > about the provided images.
> >
> > I'm not sure whether we already have some kind of alternative solution to
> > this, let me know if you know about any. Further ideas about this topic
> > would also be helpful.
>
> The JPEG driver already exposes EXIF information if found :
>
> $ gdalinfo ../autotest/gdrivers/data/albania.jpg
> Driver: JPEG/JPEG JFIF
> Files: ../autotest/gdrivers/data/albania.jpg
> Size is 361, 260
> Coordinate System is `'
> Metadata:
> [...]
>   EXIF_GPSLatitude=(41) (1) (22.91)
>   EXIF_GPSLatitudeRef=N
>   EXIF_GPSLongitude=(19) (55) (42.35)
>   EXIF_GPSLongitudeRef=E
> [...]
>
> $ gdalinfo ../autotest/gcore/data/exif_and_gps.tif -mdd EXIF
> Driver: GTiff/GeoTIFF
> Files: ../autotest/gcore/data/exif_and_gps.tif
> Size is 1, 1
> Coordinate System is `'
> [..]
> Metadata (EXIF):
> [...]
>   EXIF_GPSLatitude=(77) (5) (60)
>   EXIF_GPSLatitudeRef=S
>   EXIF_GPSLongitude=(34) (12) (0)
>   EXIF_GPSLongitudeRef=E
> [..]
>
> Are you thinking to other raster formats to extract EXIF info from? To my
> knowledge, the JPEG driver, and recently the GTiff driver, are the only one
> that extract EXIF for now. I see that the JPEG driver exposes it in the
> default metadata domain, whereas I chose EXIF for the GTiff driver. For
> GTiff,
> the specific EXIF metadata domain seemed better to me to avoid 'polluting'
> the
> default metadata domain, but I didn't want to change the JPEG driver at
> that
> point. But this would probably requires some harmonization.
>
> So with some scripting, you could create for example a point shapefile,
> with
> the filename as attribute and GPS position as geometry.
>
> In its syntax, this could be something similar to gdaltindex.
>
> Doing that as a OGR driver would be also doable of course. The only point
> to
> solve is the definition of the connexion string to specify the image set.
>
> >
> > Best regards,
> >
> > Tamas
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] New OGR driver: Imageset (Tamas Szekeres)

[Tamas Szekeres]

Daniel,

Thanks for the input, I'm still thinking whether an offline or an online
solution would be more sufficient. OGR driver would somewhat be simple even
if it's used to convert the data source to shapefile directly (ogr2ogr).
Scripting requires the user to set up further environments (Python, C# Java
whatever) which is more complicated to utilize in most cases.

Best regards,

Tamas



2012/7/23 Daniel Clewley 

> Hi Tamas,
>
> Sounds like a great idea. I don't know if it's of use but I recently put
> together a python script to create KMZ files of geotagged photos using the
> Python Imaging Library to read EXIF data. It also exports a list of photos
> and coordinates as a CSV file, for loading into a GIS. You could use OGR to
> output a vector data source instead.
>
> The script can be downloaded from here:
>
> http://dropbox.aber.ac.uk/?**KJHsTqst<http://dropbox.aber.ac.uk/?KJHsTqst>
>
> Thanks,
>
> Dan
>
> On Mon, 23 Jul 2012 09:51:14 +0200, Tamas Szekeres wrote:
>
> > Hi All,
> >
> > We're thinking about implementing a new OGR driver which would
> > represent a set of images as a vector data source. The images are
> > taken from any GPS compatible mobile device, and each picture would be
> > represented as a point feature, the positions would be extracted from
> > the exif information. The file name and path would be provided as an
> > attribute for each feature. This data source could then be used by
> > higher level apps to provide symbols at the picture locations in the
> > map and display the picture when the feature is selected. The driver
> > would definitely use GDAL to extract information about the provided
> > images.
> >
> > I'm not sure whether we already have some kind of alternative solution
> > to this, let me know if you know about any. Further ideas about this
> > topic would also be helpful.
> >
> > Best regards,
> >
> > Tamas
> >
>
> __**_
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/**mailman/listinfo/gdal-dev<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] New OGR driver: Imageset

[Tamas Szekeres]

Hi Daniel,

Thanks for your comments. Your concerns are valid about the
performance. But writing a script to convert images to shapefiles would
likely provide similar performance. With regards to the usability, having a
driver (and the use of ogr2ogr) would be more convenient even if that's
used mostly as an offline solution. I'm not too satisfied with the practice
of outsourcing significant tasks to external (language specific) scrips as
"official" tools. This requires the user to be prepared to install further
things (like runtime environments, additional libraries etc) in order to
have the things up and running. The concept of having a new driver would
provide further possibilities related to the common object model (like
having OGR SQL to work)

Best regards,

Tamas




2012/7/23 Daniel Morissette 

> If I understand correctly, in the Open() call, this driver would open each
> image file to read its EXIF info and index the files in memory? This would
> work fine with a dozen images, but as the number of images increases the
> performance will suffer a lot and this would become unusable in apps such
> as MapServer, and even for Desktop apps with hundreds of images.
>
> If I needed this kind of functionality myself I would use a script to
> create an OGR point file as suggested by Even, to avoid the overhead caused
> by opening all the images.
>
> My 0.02$
>
> Daniel
>
>
>
> On 12-07-23 5:27 AM, Tamas Szekeres wrote:
>
>> Hi Even,
>>
>> I just want to use the directory name to define the connection to the
>> images, we could also provide to scan the files in subdirectories if
>> needed. I would prefer to have a new driver not just an offline tool for
>> creating OGR datasets, in this case many existing applications (like
>> MapServer) would be capable to utilize this feature.
>> I could imagine a driver configuration file to specify which driver
>> should be used for a particular image format and where the specific
>> information is located, I don't require to harmonize the metadata
>> structure at this time. We should probably allow mixing jpegs and tiffs
>> in the same directory, but the configuration should specify how the
>> similar attributes are provided by each (sub)driver.
>>
>> Best regards,
>>
>> Tamas
>>
>>
>>
>> 2012/7/23 Even Rouault > <mailto:even.rouault@mines-**paris.org >>
>>
>>
>> Le lundi 23 juillet 2012 09:51:14, Tamas Szekeres a écrit :
>>  > Hi All,
>>  >
>>  > We're thinking about implementing a new OGR driver which would
>> represent a
>>  > set of images as a vector data source. The images are taken from
>> any GPS
>>  > compatible mobile device, and each picture would be represented
>> as a point
>>  > feature, the positions would be extracted from the exif
>> information. The
>>  > file name and path would be provided as an attribute for each
>> feature. This
>>  > data source could then be used by higher level apps to provide
>> symbols at
>>  > the picture locations in the map and display the picture when the
>> feature
>>  > is selected. The driver would definitely use GDAL to extract
>> information
>>  > about the provided images.
>>  >
>>  > I'm not sure whether we already have some kind of alternative
>> solution to
>>  > this, let me know if you know about any. Further ideas about this
>> topic
>>  > would also be helpful.
>>
>> The JPEG driver already exposes EXIF information if found :
>>
>> $ gdalinfo ../autotest/gdrivers/data/**albania.jpg
>> Driver: JPEG/JPEG JFIF
>> Files: ../autotest/gdrivers/data/**albania.jpg
>> Size is 361, 260
>> Coordinate System is `'
>> Metadata:
>> [...]
>>EXIF_GPSLatitude=(41) (1) (22.91)
>>EXIF_GPSLatitudeRef=N
>>EXIF_GPSLongitude=(19) (55) (42.35)
>>EXIF_GPSLongitudeRef=E
>> [...]
>>
>> $ gdalinfo ../autotest/gcore/data/exif_**and_gps.tif -mdd EXIF
>> Driver: GTiff/GeoTIFF
>> Files: ../autotest/gcore/data/exif_**and_gps.tif
>> Size is 1, 1
>> Coordinate System is `'
>> [..]
>> Metadata (EXIF):
>> [...]
>>EXIF_GPSLatitude=(77) (5) (60)
>>EXIF_GPSLatitudeRef=S
>>EXIF_GPSLongitude=(34) (12) (0)
>>EXIF_GPSLongitudeRef=E
>> [..]
>>
>> Are you thinking to other raste

Re: [gdal-dev] GDAL - Python - ArcGIS10.1

[Tamas Szekeres]

Jay,

Add the directory of the GDAL installation to the beginning of the system
PATH.
Or alternatively, you can run the GDAL console (to set the environment
correctly) and then start python.exe from this command prompt.

Best regards,

Tamas


2012/8/6 Jay L. 

> All,
>
> I am trying to get the gdal python bindings working with an ArcGIS 10.1
> installation.
>
> I grabbed the core from gisinternals.com/sdk (thanks Tamas!) and
> installed both the 1500 core files (MVS 2008) and the python 2.7 bindings.
> I appended the path as necessary and added the GDAL_DATA directory.  The
> gdal installation appears to be working wonderfully with gdal_translate,
> gdalinfo, and ogr2ogr all functioning as expected.
>
> Any of the python scripts and a straigh import of gdal or ogr are
> failing.  Stack trace below.  Any ideas?  This is a new import error for me.
>
> I attempted the import both from the root directory and the directory gdal
> is in (thinking it still could have been a PATH issue).  I also tried both
> the stable and the nightly builds to see if that was the issue.  Nada.
>
> Thanks,
> Jay
>
> Microsoft Windows [Version 6.1.7601]
> Copyright (c) 2009 Microsoft Corporation.  All rights reserved.
>
> C:\Users\arc_user>python
> Python 2.7.2 (default, Jun 12 2011, 15:08:59) [MSC v.1500 32 bit (Intel)]
> on win
> 32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import gdal
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "C:\Python27\ArcGIS10.1\lib\site-packages\gdal.py", line 2, in
> 
> from osgeo.gdal import deprecation_warn
>   File "C:\Python27\ArcGIS10.1\lib\site-packages\osgeo\__init__.py", line
> 21, in
>  
> _gdal = swig_import_helper()
>   File "C:\Python27\ArcGIS10.1\lib\site-packages\osgeo\__init__.py", line
> 17, in
>  swig_import_helper
> _mod = imp.load_module('_gdal', fp, pathname, description)
> ImportError: DLL load failed: The device is not ready.
> >>>
>
> ___
> 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] Compiling libCurl with GDAL v1.9

[Tamas Szekeres]

Paul,

If you want to recompile libcurl, I'd suggest to utilize the provided cmake
approach to create a working solution file. All other approaches (on
windows) lead to various mysterious issues which are better to avoid.

Best regards,

Tamas



2012/8/13 Paul Meems 

> Hi all,
>
> I'm trying (again) to compile GDAL with libCurl support.
> I'm on Windows using VS2008Pro.
> I'm using GDALv1.9.
>
> I went to this page http://trac.osgeo.org/gdal/wiki/LibCurl
> On this page a link is provided to a package.
> That link is no longer working.
>
> So I tried looking for the package myself.
> I've downloaded curl-7.27.0-ssl-sspi-zlib-static-bin-w32.zip from
> fossies.org and curl-7.27.0-devel-mingw32.zip from haxx.se both both
> don't have the needed lib files.
>
> So my question is:
> How to obtain the correct libCurl package?
>
> Thanks,
>
> Paul
>
>  *Paul Meems *
> Release manager, configuration manager
> and forum moderator of MapWindow GIS.
> www.mapwindow.org
>
> Owner of MapWindow.nl - Support for
> Dutch speaking users.
> www.mapwindow.nl
>
> *
> *
>
>
> ___
> 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] Compiling libCurl with GDAL v1.9

[Tamas Szekeres]

I recently used this option (curl 7.27.0), but a client reported
performance problems with this approach. May be I would have been trying to
disable one or more services which are compiled by default causing this
side effect, but I rather went back to the original cmake approach
instead. I've never experienced issues like this by using the cmake builds.

Best regards,

Tamas



2012/8/13 Jeff McKenna 

> Hi Paul,
>
> I compile libCurl with the MSVC compiler, and I follow the "MSVC from
> command line" instructions at http://curl.haxx.se/docs/install.html
>
> I set the ZLIB and OPENSSL paths as suggested as well.
>
> -jeff
>
>
>
> --
> Jeff McKenna
> MapServer Consulting and Training Services
> http://www.gatewaygeomatics.com/
>
>
>
> On 12-08-13 8:12 AM, Paul Meems wrote:
> > Hi all,
> >
> > I'm trying (again) to compile GDAL with libCurl support.
> > I'm on Windows using VS2008Pro.
> > I'm using GDALv1.9.
> >
> > I went to this page http://trac.osgeo.org/gdal/wiki/LibCurl
> > On this page a link is provided to a package.
> > That link is no longer working.
> >
> > So I tried looking for the package myself.
> > I've downloaded curl-7.27.0-ssl-sspi-zlib-static-bin-w32.zip from
> > fossies.org  and curl-7.27.0-devel-mingw32.zip from
> > haxx.se  both both don't have the needed lib files.
> >
> > So my question is:
> > How to obtain the correct libCurl package?
> >
>
>
>
> ___
> 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] SQL Server Driver

[Tamas Szekeres]

Hi,

Assuming you refer to the MSSQL driver the driver should provide fast data
retrieval, but hasn't yet been optimized to provide fast data upload.
Currently the MSSQL driver use WKT for the geometries when submitting data
to the server, while when retrieving data we use the native
SqlGeometry/SqlGeography serialization format.

Not sure what you mean by "do not do bulk insert". How your own routine is
looking like? Is this a .NET based program (using SqlGeometry by default)?

Best regards,

Tamas



2012/8/25 Duchesne, Jimmy 

> Hello,
>
> ** **
>
> I’ve been using SQL Server Driver for a few days now, and I noticed it was
> very slow, whatever the parameters, such as GT, I was using.
>
> ** **
>
> I need to insert millions of rows in a table.
>
> ** **
>
> To give you an idea, it takes around 1 minute to import 10k records with
> the driver
>
> ** **
>
> On the other hand, if I write my own routine which reads a MapInfo file
> and does batch insert into the database, I can insert over 125k records per
> minute.
>
> ** **
>
> I tried reading the same TAB file with ogr2ogr but writing to PostGis and
> noticed the speed was about the same than my routine, which is enough for
> my needs.
>
> ** **
>
> Would it be possible that the SQL Server Driver does not do bulk insert?**
> **
>
> ** **
>
> Thanks for the help.
>
> ** **
>
> *Jimmy Duchesne ***
>
> ** **
>
> ___
> 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] SQL Server Driver

[Tamas Szekeres]

Jimmy,

Seems we can get the significant improvement by using bulk inserts then.
You may submit a ticket to keep this enhancements in scope.
Some of the guys used the driver successfully by using FreeTDS on Linux.

Best regards,

Tamas



2012/8/27 Duchesne, Jimmy 

> Thanks for the answers guys.
>
> What you're saying concurs with what I was experiencing, and I believe,
> what I was seeing with the SQL Server Management profiler.
>
> Also, I don't know if inserting with something else than WKT would
> actually improve the performance because my test, bulk inserts done with
> Java, were also inserting using WKT.
>
> Finally, just to be sure, is there any issue with using this driver on a
> Linux OS?
>
> Jimmy.
>
> -Original Message-
> From: fwarmer...@gmail.com [mailto:fwarmer...@gmail.com] On Behalf Of
> Frank Warmerdam
> Sent: August-24-12 6:39 PM
> To: Duchesne, Jimmy
> Cc: gdal-dev@lists.osgeo.org; Szekeres Tamás
> Subject: Re: [gdal-dev] SQL Server Driver
>
> Jimmy,
>
> From an examination of MSSQLSpatialTableLayer::CreateFeature() it
> appears a regular INSERT statement is done for each feature written to
> the db rather than any sort of bulk mechanism.  I could be missing
> something of course.  Hopefully Tamas will provide a more experienced
> answer.
>
> Best regards,
> Frank
>
>
> On Fri, Aug 24, 2012 at 3:03 PM, Duchesne, Jimmy 
> wrote:
> > Hello,
> >
> >
> >
> > I've been using SQL Server Driver for a few days now, and I noticed it
> was
> > very slow, whatever the parameters, such as GT, I was using.
> >
> >
> >
> > I need to insert millions of rows in a table.
> >
> >
> >
> > To give you an idea, it takes around 1 minute to import 10k records with
> the
> > driver
> >
> >
> >
> > On the other hand, if I write my own routine which reads a MapInfo file
> and
> > does batch insert into the database, I can insert over 125k records per
> > minute.
> >
> >
> >
> > I tried reading the same TAB file with ogr2ogr but writing to PostGis and
> > noticed the speed was about the same than my routine, which is enough
> for my
> > needs.
> >
> >
> >
> > Would it be possible that the SQL Server Driver does not do bulk insert?
> >
> >
> >
> > Thanks for the help.
> >
> >
> >
> > Jimmy Duchesne
> >
> >
> >
> >
> > ___
> > gdal-dev mailing list
> > gdal-dev@lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
>
> --
>
> ---+--
> I set the clouds in motion - turn up   | Frank Warmerdam,
> warmer...@pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush| Geospatial Software Developer
> ___
> 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] gdal_wrap dll

[Tamas Szekeres]

Hi,

gdal_wrap.dll is not a managed assembly, you should not set reference to
this dll.
gdal_csharp.dll loads gdal_wrap.dll internally (assuming it's location is
added to the PATH environment setting)

Best regards,

Tamas



2012/9/10 Neelima Emmani 

>  Hi All,
> I am trying to get gdal for c#. For that, I have taken gdal binaries from
> the below link
>  http://www.gisinternals.com/sdk/.  As
> I am using Microsoft Visual Studio 9.0 and the system is windows 64 bit, I
> chose the compiler msvc2008(win64)-development.From the list of downloads
> under this link , I chose gdal-20dev-1500-x64-core.msi and
> gdal-20dev-1500-x64-ecw.msi. These were installed under the c:/program
> files with a folder name GDAL. I have my visual studio under c:/program
> files(x86). And then , I have set my system environment path to c:/program
> files/GDAL.
>
> After all this, I opened a new c# console application where i was
> successful in adding references like gdal_csharp, ogr_csharp, osr_csharp
> but could not add gdal_wrap.dll. The system is popping me up with the
> following error
>
> A reference to 'C:\Program Files\GDAL\gdal_wrap.dll' could not be added.
> Please make sure that the file is accessible, and that it is a valid
> assembly or COM component.
> Can anyone suggest me how to add this dll to my project. Do i need to do
> anything to get it work?
> Awaiting reply.
>
>
> With Regards,
> Neelima Emmani
>
>
> ___
> 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] gdal_wrap dll

[Tamas Szekeres]

How does ogrinfo recognize this file?
As far as I remember s57 requires the GDAL_DATA environment setting, for
example:

Gdal.SetConfigOption("GDAL_DATA", "path to gdal-data");

Best regards,

Tamas


2012/9/10 Neelima Emmani 

>  Hi Tamas,
> Agreeing with you . I just gave a test with a small piece of code.Code
> goes as below -
>
> using System;
> using System.Collections.Generic;
> using System.Linq;
> using System.Text;
> using OSGeo.GDAL;
> using OSGeo.OGR;
> using OSGeo.OSR;
>
> namespace test_10_09_2012
> {
> class Program
> {
> static void Main(string[] args)
> {
> OSGeo.GDAL.Gdal.AllRegister();
> String filename = @"xx.000";
> OSGeo.GDAL.Dataset ds = OSGeo.GDAL.Gdal.Open(filename,
> OSGeo.GDAL.Access.GA_ReadOnly);
> if (ds == null)
>{
> Console.WriteLine("Can't open " + filename);
> System.Environment.Exit(-1);
> }
> Console.WriteLine("S57 dataset parameters:");
> Console.WriteLine("  Projection: " + ds.GetProjectionRef());
>
> OSGeo.GDAL.Driver drv = ds.GetDriver();
>
> if (drv == null)
> {
> Console.WriteLine("Can't get driver.");
> System.Environment.Exit(-1);
> }
>
> Console.WriteLine("Using driver " + drv.LongName);
> }
> }
> }
>  This throws me an exception in reading the file format. It says that it
> is not a recognized as a supported  file format .
> Do you have any idea.
>
> With Regards,
> Neelima Emmani
>
>   --
> *From:* Tamas Szekeres [szeker...@gmail.com]
> *Sent:* Monday, September 10, 2012 1:20 PM
> *To:* Neelima Emmani
> *Subject:* Re: [gdal-dev] gdal_wrap dll
>
>  Hi,
>
>  gdal_wrap.dll is not a managed assembly, you should not set reference to
> this dll.
> gdal_csharp.dll loads gdal_wrap.dll internally (assuming it's location is
> added to the PATH environment setting)
>
>  Best regards,
>
>  Tamas
>
>
>
> 2012/9/10 Neelima Emmani 
>
>>  Hi All,
>> I am trying to get gdal for c#. For that, I have taken gdal binaries from
>> the below link
>>  http://www.gisinternals.com/sdk/. <http://www.gisinternals.com/sdk/> As
>> I am using Microsoft Visual Studio 9.0 and the system is windows 64 bit, I
>> chose the compiler msvc2008(win64)-development.From the list of downloads
>> under this link , I chose gdal-20dev-1500-x64-core.msi and
>> gdal-20dev-1500-x64-ecw.msi. These were installed under the c:/program
>> files with a folder name GDAL. I have my visual studio under c:/program
>> files(x86). And then , I have set my system environment path to c:/program
>> files/GDAL.
>>
>> After all this, I opened a new c# console application where i was
>> successful in adding references like gdal_csharp, ogr_csharp, osr_csharp
>> but could not add gdal_wrap.dll. The system is popping me up with the
>> following error
>>
>> A reference to 'C:\Program Files\GDAL\gdal_wrap.dll' could not be added.
>> Please make sure that the file is accessible, and that it is a valid
>> assembly or COM component.
>> Can anyone suggest me how to add this dll to my project. Do i need to do
>> anything to get it work?
>> Awaiting reply.
>>
>>
>> With Regards,
>> Neelima Emmani
>>
>>
>> ___
>> 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] Layer creation option FID (Spatialite, MSSQL)

[Tamas Szekeres]

2012/9/10 Jeremy Palmer 

> Any limiting factors in improving the Spatialite and MSSQLSpatial drivers
> to allow defining the feature ID column LCO like the PostgreSQL (FID) or
> FileGDB (OID_NAME) drivers?
>

Yes it could be implemented. The limiting factor is the available spare
time ;-)



>
> Also, do Spatialite, MSSQL user defined tables with PKs already set work
> correctly in OGR?
>
>
What do you mean by "working correctly"? Did you find issues?

Best regards,

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

Re: [gdal-dev] Motion: Release 1.9.2

[Tamas Szekeres]

+1

Tamas



2012/10/9 Frank Warmerdam 

> Motion: The GDAL/OGR 1.9.2RC2 release is promoted to be the
> official GDAL/OGR 1.9.2 release.
>
> ---
>
> PSC members are encouraged to review the release candidate
> and vote.  Non-PSC members are encouraged to review the
> release candidate and comment here on problems.
>
> The motion will be open for two days for voting.
>
> +1 Frank
>
> --
>
> ---+--
> I set the clouds in motion - turn up   | Frank Warmerdam,
> warmer...@pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush| Geospatial Software Developer
>
>
> ___
> 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] Ogr and Dwg via Teigha (in C#)

[Tamas Szekeres]

Noon,

The C# bindings provided by OGR provide a common interface for all drivers.
You can use the Datasource class for each of the drivers . You can
instatiate the driver by using the driver specific connection string (ie by
using Ogr.Open) or obtain a specific driver (Ogr.GetDriverByName)  and open
the datasource on that (Driver.Open).

You may however need to compile the DWG driver with OGR if that is provided
by default with the binary distribution you are using. According to your
concerns, enabling or not enabling the driver should not affect compilation
of the SWIG interface.

Best regards,

Tamas



2012/10/28 Noon Silk 

> Hi All,
>
>  I'm trying to read DWG files and output OGR layers. I note, actually,
> that there exists an OgrDwgDatasource in the C++; but I don't believe
> it is built by default.
>
>  My difficutly comes in in that I'm using the SWIG-generated bindings.
> I tried porting the C++ datasource code to C#, but stumbled upon a
> problem - SWIG hadn't generated a usable OSGeo.OGR.DataSource. The
> problem is, when you want to implement your subclass, you need to pass
> some information to the constructor that you can't obtain (i.e. a new
> instance of the DataSource). The reason why, I suppose, is that SWIG
> hasn't even generated a newDatasource() method. So I find myself
> wondering why, and being a bit confused.
>
>  I think basically I must be approaching this wrong. I'm supposing
> what I should do is to compile OGR with DWG support (i.e. use the
> OgrDwgDataSource.cpp that exists in ogr_frmts/dwg) and then have it
> generate SWIG bindings from here. My concern with this is that,
> glancing at the build scripts, it looks like it will work with
> "DWGDirect", which I think is a precursor to Teigha. So I'm slightly
> concerned that following this path will lead to build difficulties.
>
>  I suppose my question here is; what is the standard way to do this? I
> would like to make use of the stuff already pre-written in Ogr to do
> this, but I could be convinced that it's just better to approach it
> from the Teigha side; converting to OGR myself. But of course I'd far
> prefer just to simply change a small build parameter, get all the
> correct SWIG bindings, and then just perform everything in C# ...
>
>  Appreciate any thoughts.
>
> --
> Noon
> ___
> 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] Ogr and Dwg via Teigha (in C#)

[Tamas Szekeres]

This doc is fairly old (written by me ;-) , but the build process hasn't
been changed for years. What did you mean by "it doesn't appear to be
included as part of any existing build/packaging process"?

Best regards,

Tamas



2012/10/29 Noon Silk 

> Answering my own question, I've found that this is documented here:
>
>  - http://trac.osgeo.org/gdal/wiki/GdalOgrCsharpCompile
>
> I note that it doesn't appear to be included as part of any existing
> build/packaging process in the source when I grabbed it
> (release-1400).
>
> --
> Noon
>
>
> On Mon, Oct 29, 2012 at 11:13 AM, Noon Silk 
> wrote:
> > Hi Tamas,
> >
> >  Thanks.
> >
> >  I'm partly towards getting a build going; but am I to understand that
> > generating the SWIG bindings is best done from linux? (That is, I note
> > that the code to generate the bindings is in a shell script; I'm
> > currently attempting to figure out how to run it, but I'm not sure if
> > there is a better way; I.e. I'm running "mkinterface.sh", which I
> > found from "mkdgdaldist.sh").
> >
> > --
> > Noon
> >
> >
> > On Mon, Oct 29, 2012 at 4:49 AM, Tamas Szekeres 
> wrote:
> >> Noon,
> >>
> >> The C# bindings provided by OGR provide a common interface for all
> drivers.
> >> You can use the Datasource class for each of the drivers . You can
> >> instatiate the driver by using the driver specific connection string
> (ie by
> >> using Ogr.Open) or obtain a specific driver (Ogr.GetDriverByName)  and
> open
> >> the datasource on that (Driver.Open).
> >>
> >> You may however need to compile the DWG driver with OGR if that is
> provided
> >> by default with the binary distribution you are using. According to your
> >> concerns, enabling or not enabling the driver should not affect
> compilation
> >> of the SWIG interface.
> >>
> >> Best regards,
> >>
> >> Tamas
> >>
> >>
> >>
> >> 2012/10/28 Noon Silk 
> >>>
> >>> Hi All,
> >>>
> >>>  I'm trying to read DWG files and output OGR layers. I note, actually,
> >>> that there exists an OgrDwgDatasource in the C++; but I don't believe
> >>> it is built by default.
> >>>
> >>>  My difficutly comes in in that I'm using the SWIG-generated bindings.
> >>> I tried porting the C++ datasource code to C#, but stumbled upon a
> >>> problem - SWIG hadn't generated a usable OSGeo.OGR.DataSource. The
> >>> problem is, when you want to implement your subclass, you need to pass
> >>> some information to the constructor that you can't obtain (i.e. a new
> >>> instance of the DataSource). The reason why, I suppose, is that SWIG
> >>> hasn't even generated a newDatasource() method. So I find myself
> >>> wondering why, and being a bit confused.
> >>>
> >>>  I think basically I must be approaching this wrong. I'm supposing
> >>> what I should do is to compile OGR with DWG support (i.e. use the
> >>> OgrDwgDataSource.cpp that exists in ogr_frmts/dwg) and then have it
> >>> generate SWIG bindings from here. My concern with this is that,
> >>> glancing at the build scripts, it looks like it will work with
> >>> "DWGDirect", which I think is a precursor to Teigha. So I'm slightly
> >>> concerned that following this path will lead to build difficulties.
> >>>
> >>>  I suppose my question here is; what is the standard way to do this? I
> >>> would like to make use of the stuff already pre-written in Ogr to do
> >>> this, but I could be convinced that it's just better to approach it
> >>> from the Teigha side; converting to OGR myself. But of course I'd far
> >>> prefer just to simply change a small build parameter, get all the
> >>> correct SWIG bindings, and then just perform everything in C# ...
> >>>
> >>>  Appreciate any thoughts.
> >>>
> >>> --
> >>> Noon
> >>> ___
> >>> gdal-dev mailing list
> >>> gdal-dev@lists.osgeo.org
> >>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
> >>
> >>
> >
> >
> >
> > --
> > Noon Silk
> >
> > Fancy a quantum lunch? https://sites.google.com/site/quantumlunch/
> >
> > "Every morning when I wake up, I experience an exquisite joy — the joy
> > of being this signature."
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Ogr and Dwg via Teigha (in C#)

[Tamas Szekeres]

You might also take a look at the -dev packages at
http://www.gisinternals.com/sdk/
The compilation is controlled by a single makefile, so you can use:

nmake gdal
nmake gdal-csharp

to achieve the desired result.

Best regards,

Tamas



2012/10/29 Noon Silk 

> On Mon, Oct 29, 2012 at 9:47 PM, Tamas Szekeres 
> wrote:
> > This doc is fairly old (written by me ;-) , but the build process hasn't
> > been changed for years. What did you mean by "it doesn't appear to be
> > included as part of any existing build/packaging process"?
>
> I guess what I meant here is that the building of the swig bindings
> for some particular language aren't in, say, the root "makefile.vc".
> And the scripts that perhaps do do some sort of build (though, not
> that I'm actually using at the moment) need to be called directly.
>
> I.e. I had sort of assumed that I'd end up, at some point, with the
> swig stuff distributed in the same fashion that I do with the rest of
> gdal, when I do "nmake ... install" (in the end I've just hacked the
> scripts to do this, but clearly that's not ideal ...)
>
> Anyway, thanks for your help, and there only remains one problem to
> solve (I think with the signing of the swig generated stuff; .NET is
> upset about some sort of code calling native libs ...) then it might
> just work!
>
>
> > Best regards,
> >
> > Tamas
>
> --
> Noon
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] state of RFC #26 adoption?

[Tamas Szekeres]

Hi Konstantin,

As far as I remember, I'd require some further testing efforts to make sure
the code is feasible in all conditions. This RFC targets a fairly
substantial part of the code, that should be handled with care. But the
client who required this fix (with the intent to fix problems addressing
TMS tiles at large zoom levels) went ahead with another solution to the
problem, so this addition has become quite neglected.

Did you run into a similar issue, which would also validate this change?

Best regards,

Tamas




2012/11/1 Konstantin Baumann 

> Hi all,
>
> what is the current state of the adoption and implementation of RFC #26 (
> http://trac.osgeo.org/gdal/wiki/rfc26_blockcache)? Are there any plans to
> finalize the development for it?
>
> -Konstantin
> ___
> 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] Ogr and Dwg via Teigha (in C#)

[Tamas Szekeres]

Noon,

As far as I see the DWG driver is compiled as a plugin so you should either
place it into a /gdalplugins subdirectory from where your application is
running, or set the location of this dll in the GDAL_DRIVER_PATH
environment variable.
Also make sure the location of the dll-s from the dependent libs are also
added in PATH.

Best regards,

Tamas




2012/11/3 Noon Silk 

> Hi,
>
>  So, further to this, I've not had much luck with my previous
> approach. I'm going to now try this method; but I kind of want to
> understand why what I tried didn't work.
>
>  What I mean by "Didn't work" is that my requests to open DWG files,
> or just grab an instance of the DWG driver, didn't work.
>
>  I ask for an instance like so (in C#):
>
>  Ogr.RegisterAll();
>  Driver d = Ogr.GetDriverByName("DWG");
>
>  "d" comes back as null. So, I expected it to return something given
> that I thought I was correctly "enablding" the DWG library. But, I
> also checked to see if the number of available drivers changed, after
> me doing what I would've expected to result in the enablding. Sadly,
> it didn't. So I can only assume that I didn't enanble it correctly.
>
>  So, my process for enabling the DWG driver was basically to allow it
> to be compiled as part of the "gdal\ogr\ogrsf_frmts\makefile.vc" (by
> adding in the directory and the obj files). I also set up the required
> Teigha libraries by uncommenting and correctly setting the particular
> bits of nmake.opt.
>
>  Then the only other change I made was to generate the SWIG bindings.
>
>  Is this the correct way to enable the dwg bindings? Is there
> something obvious I've missed? Would linking this other -dev build
> script with the particular source work better?
>
> Thanks,
> --
> Noon
>
>
>
>
> On Fri, Nov 2, 2012 at 9:30 AM, Noon Silk 
> wrote:
> > On Mon, Oct 29, 2012 at 11:34 PM, Tamas Szekeres 
> wrote:
> >> You might also take a look at the -dev packages at
> >> http://www.gisinternals.com/sdk/
> >> The compilation is controlled by a single makefile, so you can use:
> >>
> >> nmake gdal
> >> nmake gdal-csharp
> >
> > Thanks; I happened to grab the "MSVC2005 (Win64) -development", which
> > doesn't have that ..., I'll give this a go.
> >
> >
> >> to achieve the desired result.
> >>
> >> Best regards,
> >>
> >> Tamas
> >
> > --
> > Noon
>
___
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#?

[Tamas Szekeres]

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 

> 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

Re: [gdal-dev] Motion: Release next major GDAL version as GDAL/OGR 1.10

[Tamas Szekeres]

+1

Tamas


2012/11/9 Even Rouault 

> Motion: The next major GDAL version released from trunk will be called
> GDAL/OGR 1.10.
>
> To take into account 2-figure numbers in the components of the version
> number,
> the GDAL_VERSION_NUM macro will be changed accordingly as :
>
> #  define GDAL_VERSION_NUM
>
> (GDAL_VERSION_MAJOR*100+GDAL_VERSION_MINOR*1+GDAL_VERSION_REV*100+GDAL_VERSION_BUILD)
>
> A new macro will be added so that users don't have to do all the above
> multiplications :
>
> #define GDAL_COMPUTE_VERSION(maj,min,rev)
> (maj*100+min*1+rev*100)
>
> (Note: as raised by Mateusz, I've dropped the 'build' argument in the
> macro,
> since it has never been used in the past and it is unlikely code would
> depend
> on that)
>
> 
>
> Hi,
>
> Not surprisingly when it is related to preferences on version numbering,
> the
> previous discussion thread has not lead to a clear consensus on the topic,
> but
> we need to make a decision soon so that users can anticipate the
> adaptations
> needed in their code.
>
> 1.10 seems the more logical option to me, even if that implies changing the
> way we compute GDAL_VERSION_NUM, which I don't anticipate to cause
> problems to
> existing code. There are also a few existing documentation pages in
> drivers or
> utilities that mention GDAL 2.0 that will need to be changed, but I'll take
> care of this if the motion is approved (some sed magic should do this).
>
> +1 Even
> ___
> 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] Absolutely no progress trying to compile GDAL with Oracle support on Windows

[Tamas Szekeres]

GDAL plugins should either be installed into a /gdalplugins subdirectory
from where the executable is running or set GDAL_DRIVER_PATH to point to
the directory containing these files. With regards to
gisinternalsboth the oracle and the
filegdb plugins are provided, however you must copy
them to the desired locations manually. You should also download and
provide binaries of the proper version of the OCI (ie. instantclient) and
the FileGDB libraries being available in the PATH, which cannot be
distributed from gisinternals  due to
licensing restrictions.

Best regards,

Tamas



2012/11/28 cheesybiscuits 

> Eli - thanks a bunch for mentioning the .bat file - that got Oracle support
> working!
>
> I really should have seen that, and the read-me in the same directory
> telling me to run it... I've just got into a routine of getting the
> binaries, testing with the same commands, and being disappointed.
>
> This may be better placed as a separate question, but hopefully it's an
> easy
> / quick answer:
>
> Whilst Oracle support is working FileGDB is not. gisinternals.com claims
> ogrinfo --formats includes FileGDB support but I don't seem to have it. I
> have the FGDB API (version 10.0?) installed and its binaries are included
> in
> the path, but for some reason this driver isn't available.
>
> Any hints on this last problem would be great. My backup plan is exporting
> to Shp but I have some field names longer than 10 characters and I don't
> want to dive into that mess
>
>
>
> --
> View this message in context:
> http://osgeo-org.1560.n6.nabble.com/Absolutely-no-progress-trying-to-compile-GDAL-with-Oracle-support-on-Windows-tp5018926p5019199.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

Re: [gdal-dev] C# ReadRaster qustion

[Tamas Szekeres]

Felix,

You can use Band.GetOverview to get a particular overview. For an example
see:
http://trac.osgeo.org/gdal/browser/trunk/gdal/swig/csharp/apps/GDALOverviews.cs

Drivers should anyway be able to select the most reasonable overview when
reading data according to the requested extent.

Best regards,

Tamas




2013/1/22 Felix Obermaier 

> Hello,
>
> if I wish to read data from a raster band that has additional overview
> bands, do I need to determine the appropriate band myself or is that
> internally handled?
> If I have to, is there some documentation on how to determine that?
>
> Thanks
> Felix Obermaier
>
> --
> Ingenieurgruppe IVV GmbH & Co. KG
> Dipl.-Ing. Felix Obermaier
> Oppenhoffallee 171
> 52066 Aachen
>
> Telefon: +49 (241) 94691-36
> Telefax: +49 (241) 531622
> eMail: o...@ivv-aachen.de
> Internet: http://www.ivv-aachen.de
>
> Sitz der Gesellschaft: Aachen
> Amtsgericht Aachen HRA 6212
> GF: Bauassessor Dr.-Ing. Dieter Hölsken
> IVV-Management GmbH
> Amtsgericht Aachen HRB 12453
>
> ___
> 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] c# Bindings in Mono/Linux

[Tamas Szekeres]

Frank,

I've committed in the SVN trunk to produce well formed xml with the
development version. However I doubt if it causes this problem.
Probably your environment settings like incorrect LD_LIBRARY_PATH
prevents from loading the gdal so or the related so-s (like proj).
At the buildbot configurations those pathes have been set manually to
the correct directories.

Best regards,

Tamas



2008/7/21 fevans <[EMAIL PROTECTED]>:
>
> Tamas, with regards to mono/gdal bindings, I suspect I'm doing something
> wrong in the build process. Clearly the buildbots are passing.
>
> One item that's been bothering me is line 50 of "swig\csharp\GNUMakefile"
> Its generating a config-xml wrapper for the dll, but thet XML is mal-Formed.
>
> echo "" >> $*_csharp.dll.config
>
> Generates: 
> Should be: 
>
> So either these wrappers are not used, or I'm digging in the wrong place.
> The nightly builds at "http://buildbot.osgeo.org/gdal-full/"; are still
> inaccessible.
>
>
> ./mkinterface.sh
> make -f GNUmakefile
>
> 
> make test
> LC_ALL=C mono createdata.exe Data pointlayer
>
> Unhandled Exception: System.TypeInitializationException: An exception was
> thrown by the type initializer for OSGeo.OGR.gr --->
> System.TypeInitializationException: An exception was thrown by the type
> initializer for OSGeo.OGR.OgrPINVOKE --> System.TypeInitializationException:
> An exception was thrown by the type initializer for SWIGExceptionHelper --->
> Systm.DllNotFoundException: libogrcsharp.la
>  at (wrapper managed-to-native)
> SWIGExceptionHelper:SWIGRegisterExceptionCallbacks_Ogr
> (OSGeo.OGR.OgrPINVOKE/SWIGExcepionHelper/ExceptionDelegate,OSGeo.OGR.OgrPINVOKE/SWIGExceptionHelper/ExceptionDelegate,OSGeo.OGR.OgrPINVOKE/SWIGExceptinHelper/ExceptionDelegate,OSGeo.OGR.OgrPINVOKE/SWIGExceptionHelper/ExceptionDelegate,OSGeo.OGR.OgrPINVOKE/SWIGExceptionelper/ExceptionDelegate,OSGeo.OGR.OgrPINVOKE/SWIGExceptionHelper/ExceptionDelegate,OSGeo.OGR.OgrPINVOKE/SWIGExceptionHeper/ExceptionDelegate,OSGeo.OGR.OgrPINVOKE/SWIGExceptionHelper/ExceptionDelegate,OSGeo.OGR.OgrPINVOKE/SWIGExceptionHelpr/ExceptionDelegate,OSGeo.OGR.OgrPINVOKE/SWIGExceptionHelper/ExceptionDelegate,OSGeo.OGR.OgrPINVOKE/SWIGExceptionHelperExceptionDelegate)
>  at OSGeo.OGR.OgrPINVOKE+SWIGExceptionHelper..cctor () [0x0] --- End of
> inner exception stack trace ---
>
>  at OSGeo.OGR.OgrPINVOKE..cctor () [0x0] --- End of inner exception
> stack trace ---
>
>  at OSGeo.OGR.Ogr..cctor () [0x0] --- End of inner exception stack
> trace ---
>
>  at CreateData.Main (System.String[] args) [0x0]
> make: *** [test] Error 1
> 
>
>
> Tamas Szekeres wrote:
>>
>> 2008/6/11 Evans, Frank <[EMAIL PROTECTED]>:
>>> Tamas, thanks for the test-results link. I had read that tests were
>>> passing, but the log-detail provided a lot of useful info. I will try
>>> SWIG 1.3.31 this weekend, and let everyone know. I can't switch mono
>>> versions, at least not easily. Are the library outputs for the automated
>>> builds accessible?
>>>
>>
>> The build directory of the linux builders used to be accessible from
>> the following link:
>> http://buildbot.osgeo.org/gdal-full/
>> http://buildbot.osgeo.org/gdal-quick/
>>
>> But it seems like having a permission problem at the moment.
>>
>>> I know I'm asking for speculation, but do you think there's a
>>> 32-bit/64-bit issue?
>>>
>>
>> I`ve been trying on debian AMD64 as I`ve noted in my previous post so
>> I doubt that this is a 64 bit OS related issue.
>> The version of swig and mono might even more be an issue.
>>
>> Best regards,
>>
>> Tamas
>> ___
>> gdal-dev mailing list
>> gdal-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>>
>
> --
> View this message in context: 
> http://www.nabble.com/c--Bindings-in-Mono-Linux-tp17709337p18570865.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

Re: [Gdal-dev] c# Bindings in Mono/Linux

[Tamas Szekeres]

Frank,

It looks like either libgdalcsharp.la or one of it's dependencies is
not available to load, or incorrect version can be loaded with the
current LD_LIBRARY_PATH setting. Please check that the same version of
gdal is loading that the csharp bindings have been compiled against.

Best regards,

Tamas



2008/7/22 Evans, Frank <[EMAIL PROTECTED]>:
> I agree the dll.config isn't the main issue. I've tried renaming files,
> linking statically, linking dynamically. After a while, experimentation
> makes the baseline suspect, so I blast it and start over. Its definitely
> something on my end. Some basic mistake. I need to get more
> swig-knowledge.
>
> Thanks again for all your help. BTW, I ran "strace -e trace=open mono
> GDALInfo.exe ..."
>
>
> open("libgdalcsharp.la", O_RDONLY|O_LARGEFILE) = 4
> open("./.libs/libgdalcsharp.so.1", O_RDONLY) = 4
> open("libgdalcsharp.la", O_RDONLY|O_LARGEFILE) = 4
> open("./.libs/libgdalcsharp.so.1", O_RDONLY) = 4
> open("libgdalcsharp.la", O_RDONLY|O_LARGEFILE) = 4
> open("./.libs/libgdalcsharp.so.1", O_RDONLY) = 4
> open("libgdalcsharp.la", O_RDONLY|O_LARGEFILE) = 4
> open("./.libs/libgdalcsharp.so.1", O_RDONLY) = 4
> open("libgdalcsharp.la", O_RDONLY|O_LARGEFILE) = 4
> open("./.libs/libgdalcsharp.so.1", O_RDONLY) = 4
> open("libgdalcsharp.la", O_RDONLY|O_LARGEFILE) = 4
> open("./.libs/libgdalcsharp.so.1", O_RDONLY) = 4
>
> -Original Message-
> From: Tamas Szekeres [mailto:[EMAIL PROTECTED]
> Sent: Monday, July 21, 2008 5:04 PM
> To: Evans, Frank
> Cc: gdal-dev@lists.osgeo.org
> Subject: Re: [Gdal-dev] c# Bindings in Mono/Linux
>
>
> Frank,
>
> I've committed in the SVN trunk to produce well formed xml with the
> development version. However I doubt if it causes this problem.
> Probably your environment settings like incorrect LD_LIBRARY_PATH
> prevents from loading the gdal so or the related so-s (like proj).
> At the buildbot configurations those pathes have been set manually to
> the correct directories.
>
> Best regards,
>
> Tamas
>
>
>
> 2008/7/21 fevans <[EMAIL PROTECTED]>:
>>
>> Tamas, with regards to mono/gdal bindings, I suspect I'm doing
> something
>> wrong in the build process. Clearly the buildbots are passing.
>>
>> One item that's been bothering me is line 50 of
> "swig\csharp\GNUMakefile"
>> Its generating a config-xml wrapper for the dll, but thet XML is
> mal-Formed.
>>
>> echo "" >>
> $*_csharp.dll.config
>>
>> Generates: 
>> Should be: 
>>
>> So either these wrappers are not used, or I'm digging in the wrong
> place.
>> The nightly builds at "http://buildbot.osgeo.org/gdal-full/"; are still
>> inaccessible.
>>
>>
>> ./mkinterface.sh
>> make -f GNUmakefile
>>
>> 
>> make test
>> LC_ALL=C mono createdata.exe Data pointlayer
>>
>> Unhandled Exception: System.TypeInitializationException: An exception
> was
>> thrown by the type initializer for OSGeo.OGR.gr --->
>> System.TypeInitializationException: An exception was thrown by the
> type
>> initializer for OSGeo.OGR.OgrPINVOKE -->
> System.TypeInitializationException:
>> An exception was thrown by the type initializer for
> SWIGExceptionHelper --->
>> Systm.DllNotFoundException: libogrcsharp.la
>>  at (wrapper managed-to-native)
>> SWIGExceptionHelper:SWIGRegisterExceptionCallbacks_Ogr
>>
> (OSGeo.OGR.OgrPINVOKE/SWIGExcepionHelper/ExceptionDelegate,OSGeo.OGR.Ogr
> PINVOKE/SWIGExceptionHelper/ExceptionDelegate,OSGeo.OGR.OgrPINVOKE/SWIGE
> xceptinHelper/ExceptionDelegate,OSGeo.OGR.OgrPINVOKE/SWIGExceptionHelper
> /ExceptionDelegate,OSGeo.OGR.OgrPINVOKE/SWIGExceptionelper/ExceptionDele
> gate,OSGeo.OGR.OgrPINVOKE/SWIGExceptionHelper/ExceptionDelegate,OSGeo.OG
> R.OgrPINVOKE/SWIGExceptionHeper/ExceptionDelegate,OSGeo.OGR.OgrPINVOKE/S
> WIGExceptionHelper/ExceptionDelegate,OSGeo.OGR.OgrPINVOKE/SWIGExceptionH
> elpr/ExceptionDelegate,OSGeo.OGR.OgrPINVOKE/SWIGExceptionHelper/Exceptio
> nDelegate,OSGeo.OGR.OgrPINVOKE/SWIGExceptionHelperExceptionDelegate)
>>  at OSGeo.OGR.OgrPINVOKE+SWIGExceptionHelper..cctor () [0x0] ---
> End of
>> inner exception stack trace ---
>>
>>  at OSGeo.OGR.OgrPINVOKE..cctor () [0x0] --- End of inner
> exception
>> stack trace ---
>>
>>  at OSGeo.OGR.Ogr..cctor () [0x0] --- End of inner exception stack
>> trace ---
>>
>>  at CreateData.Main (S

Re: [Gdal-dev] ./configure options

[Tamas Szekeres]

Frank,

According to the previous posts you might want to check the followings:

1. Do the dependent libraries  (like libogrcsharp, gdal, proj, ..)
available to load by the system. See the LD_LIBRARY_PATH settings.
2. You can also make a test with a previous version of mono. We use
1.2.2.1 on the buildbot machine. There have been a couple of issues
reported with some of the newer versions as far as I remember.
3. You could also try using SWIG 1.3.31 like at the buildbot slaves,
but I hope the newer versions will also work.
4. You might want to try using the --without-libtool configure option,
though I'm not aware of much issues with the libtool builds (the
epimetheus slave is configure with libtool on osx) but it might also
be an issue, definitely.

Best regards,

Tamas


2008/7/22 fevans <[EMAIL PROTECTED]>:
>
> This message is related to the following thread.
> http://www.nabble.com/c--Bindings-in-Mono-Linux-td17709337.html
>
> Trying to get the c# bindings working in mono linux. The buildbots are
> working, so clearly its a configuration or env issue on my end. Does anyone
> have any general configuration advice on this? My config summary is listed
> below. The items which concern me most are:
>
> SWIG Bindings:  no
> Statically link PROJ.4:no
> enable pthread support:no
>
> Based on all my experience, the SWIG bindings don't build automatically. But
> I'm not sure if this is normal.
>
> 
> GDAL is now configured for x86_64-unknown-linux-gnu
>
>  Installation directory:/ssa/users/fevans/gdal-1.5.3dev
>  C compiler:gcc -g -O2
>  C++ compiler:  g++ -g -O2
>
>  LIBTOOL support:   yes
>
>  LIBZ support:  external
>  GRASS support: no
>  CFITSIO support:   no
>  PCRaster support:  internal
>  NetCDF support:no
>  LIBPNG support:external
>  LIBTIFF support:   external (BigTIFF=no)
>  LIBGEOTIFF support:internal
>  LIBJPEG support:   internal
>  LIBGIF support:internal
>  OGDI support:  no
>  HDF4 support:  no
>  HDF5 support:  no
>  Kakadu support:no
>  JasPer support:no
>  ECW support:   no
>  MrSID support: no
>  GRIB support:  no
>  cURL support (wms/wcs/...):yes
>  PostgreSQL support:no
>  MySQL support: no
>  Xerces-C support:no
>  Expat support: yes
>  ODBC support:  no
>  PGeo support:  no
>  OCI support:   no
>  SDE support:   no
>  DODS support:  no
>  SQLite support:no
>  DWGdirect support  no
>  PANORAMA GIS support:  no
>  INFORMIX DataBlade support:no
>  GEOS support:  yes
>
>
>  Old-gen python  no
>  SWIG Bindings:  no
>
>  Statically link PROJ.4:no
>  enable OGR building:   yes
>  enable pthread support:no
>  hide internal symbols: no
>
>
> --
> View this message in context: 
> http://www.nabble.com/.-configure-options-tp18586854p18586854.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

Re: [Gdal-dev] c# Bindings in Mono/Linux

[Tamas Szekeres]

2008/7/22 Evans, Frank <[EMAIL PROTECTED]>:
> OK, I'll zero in on that.  One thing I noticed was that the
> "swig/csharp/gdal" directory has a "makefile.vc", but not a GNUmakefile.
>

You should use:

make veryclean
make interface
make
make test

in the swig/csharp directory assuming mono and swig available in the
PATH and gdal have been configured and built previously.

Only the windows builds contain makefiles in the subsequent directories.

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

Re: [gdal-dev] Bindings for the histogram method of band

[Tamas Szekeres]

Using the same approach for the csharp bindings seems much more
complicated than the current method. Currently the caller (at the
csharp side) allocates a fixed length int array and the default
marshaler takes care of passing the array to the unmanaged (C) part of
the code. There's no need to do extra memory allocations inside the
wrapper code and using the existing 'int argin[ANY]' typemap does the
right thing when mapping this type.

Since I continue to think about a different implementation for c# I
leave the decision about this topic to the other bindings maintainers.

Best regards,

Tamas


2008/7/22 Howard Butler <[EMAIL PROTECTED]>:
>
> On Jul 22, 2008, at 9:48 AM, Ari Jolma wrote:
>
>> The trac.osgeo.org does not answer so I'll put this here.
>>
>> Hobu, would it be ok to have (int len, int *output) typemap. They can be
>> used in GetHistogram method like this (note that the API is same for C# but
>> it must use different typemaps. From Band.i:
>>
>> %typemap(check) (int len, int *output)
>> {
>> /* %typemap(check) (int len, int *output) */
>> if ($1 < 1) $1 = 1; /* stop idiocy */
>> $2 = (int *)CPLMalloc( $1 * sizeof(int) );
>>  }
>
>
> Ari,
>
> This isn't too different from what I proposed except for I think that
> abusing the check typemap like that (malloc'ing the integer array) is a
> recipe for disaster.  The check typemap could possibly be run multiple
> times, right?  Otherwise, it looks pretty close to what I had for a proposal
> http://trac.osgeo.org/gdal/changeset/14941 .
>
> I'm open to changing the GetHistogram function signature within Band.i
> however you guys wish (ideally to support just using  (int len, int *output)
> and not having a special typemap for just this function), and while it would
> be nice that we wouldn't need the #ifdefs for every possible language we
> might ever support ;), it's not the end of the world either...
>
> Howard
>
>
>
> ___
> 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] [GDAL 1.5.1] How to build and run GDAL 1.5.1 on windows

[Tamas Szekeres]

Cherif,

You have to create or use a host process which is loading and use the
gdal15.dll. Probably you can utilize one of the existing applications
like gdalinfo.exe or ogrinfo.exe have been compiled along with the
gdal project.

Best regards,

Tamas


2008/8/8 Cherif Oueslati <[EMAIL PROTECTED]>:
>
> Hello every body,
> I found a problem to run the GDAL 1.5.1 in a MS Visual Studio 2003
> Environment, to test the implementation of a driver that i developed.
> The error appears when i would like to run the project and indicates that it
> is impossible to begin the debug because it's impossible to start the
> "gdal15.dll".
> Someone suggest to me to well define the "environment variables".
> Can you tell me how could i run gdal 1.5.1 or how to set the "environment
> variables" inside the visual studio it self.
> With all my gratitude.
> Cherif.
> ___
> 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] Maintainer Activities

[Tamas Szekeres]

Bad news :-(


2008/8/8 Frank Warmerdam <[EMAIL PROTECTED]>:
> Folks,
>
> Mateusz has informed me that other commitments (school and MOSS4G) will
> make it impossible for him to spend any appreciable time on GDAL maintenance
> through to the end of his contract at the end of August.  He will also not
> be available for a new contract for a while after that.
>
> He will invoice at the end of August, but I anticipate he will only have
> used
> a modest faction of the allocated funds.
>
> Also, unfortunately, I must report that Chris Howell disappeared and has
> been
> unreachable pretty much from the point the maintainer contract was signed
> with
> him.  So, that is also a "write off", though there was no cost to us other
> than a bit of paperwork.
>
> This does put us back in the position that we are looking for a maintainer
> candidate for short or longer term.  Keep an eye out for good folks who
> might be interested.
>
> Best regards,
> --
> ---+--
> I set the clouds in motion - turn up   | Frank Warmerdam,
> [EMAIL PROTECTED]
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush| Geospatial Programmer for Rent
>
> ___
> 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] RE: progressive rendering

[Tamas Szekeres]

Norman,

It seems like adding a GDALProgressFunc like parameter to RasterIO
would be a solution but I'm not totally sure about the negaive effects
of this change since these functions are frequently used.

Most of the drivers are doing band based rasterIO so you should also
deal with Band.RasterIO in addition. The default implementation of
GDALDataset::IRasterIO is calling the band based rasterIO functions of
the drivers. In such cases how the progress func. of the band based
raserIO would be bound to the progress func of the outer dataset?

I would also be curious to know how the underlying intermediary data
should be stored and would vary between the subsequent progress
reports. For example would the raster X and Y size be different or
would it be handed as a temporary buffers and datasets or bands (like
overviews) for example?

Best regards,

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

Re: [gdal-dev] RE: progressive rendering

[Tamas Szekeres]

2008/8/19 Norman Barker <[EMAIL PROTECTED]>:
> Tamas,
>
> Thanks for the input, much appreciated since I would like to get this
> interface defined.
>
> A streaming driver so JPIPKAK for example would need to register as its
> own driver to handle urls of the type jpip://, similarly ecwp would need
> its own driver if it were to use the same callback for streaming data.
> As such the management of GDALDataset::RasterIO and Band.RasterIO would
> be the implementors responsibility, most likely this could be defined
> with references back to the parent dataset as the controller thread.
>

Norman,

Is this somewhat different as how the RasterIO is handled in the
current approach. The controller thread you mentioned would change the
synchronous behaviour of RarterIO into an asynchronous approach, yes?
In that case your callback would also denote the completion of the
overall process as well as to notify the user about a change in the
underlying data?
In any case I'd prefer a separate band/dataset level callback instead
of changing the current RasterIO signature.

The driver could also keep on the current mechanism like using the
thread of the caller to complete the RasterIO operation  in this case
the driver might want to provide that the client could re-enter into
the function from the callback in order to read out the intermediary
data from the buffers.

> The comment about raster x and y size is interesting, in the case of
> jpip raster x and y size is known as a result of the image metadata
> being transferred to the client in the initial request and can be
> handled as overviews, for other formats like MrSID, ECW then I defer to
> the better informed.
>
> JPIP does have a client cache, and this data is needed between requests,
> but I believe we can keep this data internal to the format driver.
>

I thing it's crucial how the progressive rendering capable driver
would represent the intermediary images. In case when different
buffers are used the client cannot use the same RasterIO to read out
the changes so some additional parameters/functions might have to be
introduced.

Best regards,

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

Re: [gdal-dev] RE: progressive rendering

[Tamas Szekeres]

2008/8/21 Norman Barker <[EMAIL PROTECTED]>:
> Tamas, Frank, all
>
> I have created RFC 24 on
>
> http://trac.osgeo.org/gdal/wiki/rfc24_progressive_data_support
>
> for comment; hopefully the likes of mpg, simboss and others will chip in
> as well.
>
> Currently we are just defining an interface - but I am certainly
> interested in coding the driver (and probably will) as well.
>

Norman,

Just some quick notes, I've read this over but I'm still dubious about
the issues have been manifested earlier in this thread, namely:

1. It seems we are tending to spawn new threads in every RasterIO
operations at driver level, which is quite uncovenient at the moment,
therefore it should be considered with care. Will you allow RasterIO
to be re-entered from the GDALProgFunc event handler or by another
thread? Will you provide a copy of pBuff in GDALProgFunc or the same
pointer will be passed back to the caller? How this buffer will be
protected from the simultaneous access of the multiple threads?

2. How the intermediary data will be represented in the buffer
required by the various kind of rendering methods? Will the user
re-read the whole buffer in every roundtrip, or a subset of the data
will be definied that have been changed in the meantime? I guess some
cases only the modified scanlines or reduced resolution images would
be sufficient to read.

3. Interchange between the dataset and band level functions.

4. Supporting the the current synchronous mode in addition to the
asynchronous rendering mode.

5. With regard to the SWIG / C API would this be supported by means of
adding a new function name to the API like GDALBeginRasterIO or
GDALAsyncRasterIO for instance?


> If JPIP means nothing to you then check out http://iasdemo.ittvis.com
> and in the interest of fairness have a look at Lizardtech, Erdas and
> Kakadu as well!
>

Would this driver be an extension or a replacement of the currently
existing JP2KAK implementation? I can see some kind of support inside
for JPIP as well however I'm not sure if it is fully functional.


Best regards,

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

Re: [gdal-dev] RE: progressive rendering

[Tamas Szekeres]

Norman,


Honestly I didn't follow the observations that have turned the things
into a different approach, however I agree that doing callback on
different threads might not be the most reliable option in some cases.

By reviewing the current proposal I'm a bit uncertain about how the
objective described there is related to to the title of the document.
It seems like we are tending to swich to a sequential streaming
approach instead of providing an interface to the possible progressive
rendering modes. As far as I can see we would like to notify the user
about the section that have been (or should be) updated in the buffer,
then the user is responsible to put the image together from the chunks
in order to visually render it on the screen or do some other
interesting job with that.
Assuming that we would indeed like to support the progressive
rendering, in addition to the top-down image streaming mode we might
also consider that the data may be available in such order that may
not be described easily in the interface. For example i can imageine a
one-dimensional interlacing scheme where the every 8th, 4th, 2th.. row
arrives in the subsequent iterations. Or in a 2D interlacing mode the
resolution of the image may be enhanced during the iterations. How can
we describe the modified sections in these more esoteric cases? From
the user's perspective I would rather like to see a fully prepared
intermediary image to be created by the driver in every stage of the
process. User would provide the same buffer to the driver but the
diver would be responsible to modify the data incrementally according
to the incoming segments. In some cases the whole buffer may be
modified in every iteration.

The driver should also handle the required downsampling of the rasters
according to the requested resolution of the image, how this have been
addressed with the current proposal? How the driver would prepare a
1000x1000 image into a buffer having 300*300 pixels. Would the driver
store the whole image in an in-memory dataset and rely on the current
RasterIO to copy the data to the user for example?

It seems we would like to serialize the incoming data into a message
queue by using the same chunk structure as it have been received by
the driver, however from the user's perspective it's not too
interesting to receive the data in the same fragments as it have been
received. For example the user might want to set up a timer and render
the actual snapshot of the image in every 100ms. Therefore the driver
would be responsible to put the data together by collecting every
segments that have been arrived in the meantime. From this aspect
there's no need to collect every segment in a message queue, the
driver may also use an internal buffer to collect the data between the
stages and present the whole data together to the user.

We have switched the previous pattern to another because we afraid of
the negative impacts of the multiple threads. But do we really need to
use multiple threads at all? Does the driver need to read the incoming
buffers of the socket as soon as the data have been arrived and
provide some 'real-time' action afterwards? I assume the socket
library will safely buffer the incoming data and the transmission
control protocol will be able to pause the transfer if this buffer
will eventually become full temporarily. Therefore I guess it would be
sufficient for the driver to do all the action (like reading and
preprocessing the TCP buffers) only inside the RasterIO related
functions called by the client.

In the current approach we are using a fair amount of new functions at
the interface level and rename the existing RasterIO to
ProgressiveRasterIO which is quite annoying. At the moment I don't see
the real benefit of using those new functions instead of using the
existing one in this special way.
Related to the statements above - in my opinion - only the behaviour
of the existing RasterIO should be altered, which would provide an
alternative option (in a Win32 overlapped IO fashion), according to
the following example:

1. During the dataset creation the asynchronous behaviour of the
driver for this dataset could be specified as a new dataset creation
option (like RASTERIO_MODE=ASYNC)

2. The user would use the existing RasterIO method to initiate the
operation as well as to fetch the next available data. The RasterIO
would return immediately if the buffer contains a proper set of the
intermediary data. In this case RasterIO would return a special error
code (IO_PENDING) to denote that more data will be available and the
user will have to initiate a subsequent call to RasterIO. (If we don't
like to introduce new error codes we could also use a separate
function like GetAsyncResult for this purpose).

3. The RasterIO  (or GetAsyncResult) would return no error if the
operation have been finished and no more new update will be available
in the buffer.

4. We could introduce a separate function like CancelIO to allow the
user t

Re: [gdal-dev] RE: progressive rendering

[Tamas Szekeres]

2008/8/29 Adam Nowacki <[EMAIL PROTECTED]>:
>
> In my proposal the user could:
> 1) LockBuffer()
> 2) display the current snapshot
> 3) UnlockBuffer()
> 4) sleep for 100ms ignoring the update messages (but
> NextAsyncRasterIOMessage() still has to be called to get the GARM_COMPLETE
> message)
>

Adam,

It seems you consider a multi threaded driver behaviour by default,
Why should the driver tamper the contents the buffer of the user in
the meantime at all. Wouldn't it be sufficient to update the buffer
contents in the NextAsyncRasterIOMessage call? I've mentioned that I'm
not totally sure about the necessity of using multiple threads, but
the driver could eventually collect the data in an internal temporary
buffer and copy the contents to the user buffer upon the subsequent
NextAsyncRasterIOMessage. However for collecting the data in an
internal buffer I don't think we should duplicate what the TCP/IP
driver is actually doing at the OS level.

> The RasterIO function is not renamed. A new function is added
> (AsyncRasterIO) with different behavior than the current RasterIO function.
> RasterIO function doesnt change, a full backwards compatibility.
>

I see no problem if the original RasterIO behaves differently in some
cases controlled explicitly by the user. By specifying a global
setting that RasterIO will operate in asynchronous mode at dataset
level would be enough (like using the dataset creation option or a new
flag in the dataset). I guess the programmer should take care of the
fact how the dataset have been created before. We should indeed use
the synchronous mode as the default setting.


>> Related to the statements above - in my opinion - only the behaviour
>> of the existing RasterIO should be altered, which would provide an
>> alternative option (in a Win32 overlapped IO fashion), according to
>> the following example:
>>
>> 1. During the dataset creation the asynchronous behaviour of the
>> driver for this dataset could be specified as a new dataset creation
>> option (like RASTERIO_MODE=ASYNC)
>
> With my proposal you can mix normal blocking RasterIO calls with
> AsyncRasterIO calls.

Hmmm. I don't see the related use case when the the RasterIO should be
used in synchronous and asyncronous mode with the same dataset in
parallel. However the user have the freedom to create 2 datasets
specify different IO mode and use them simultaneously.


>
>> 2. The user would use the existing RasterIO method to initiate the
>> operation as well as to fetch the next available data. The RasterIO
>> would return immediately if the buffer contains a proper set of the
>> intermediary data. In this case RasterIO would return a special error
>> code (IO_PENDING) to denote that more data will be available and the
>> user will have to initiate a subsequent call to RasterIO. (If we don't
>> like to introduce new error codes we could also use a separate
>> function like GetAsyncResult for this purpose).
>>
>> 3. The RasterIO  (or GetAsyncResult) would return no error if the
>> operation have been finished and no more new update will be available
>> in the buffer.
>>
>> 4. We could introduce a separate function like CancelIO to allow the
>> user to cancel the pending IO operation at any time.
>
> While I like the simplicity there are a few 'problems'. Identifying
> subsequent calls to RasterIO belonging to the same operation. Would it be
> the buffer pointer, together with the offset and size maybe? Possibly a lot
> of variables that have to be remembered by both the driver and user side.
> Searching a list of all open async raster io operations ? Would the buffer
> be updated with data received since last RasterIO call or a current snapshot
> ? Each open async raster io would also require its own data buffer, later
> copied in whole (or only updated regions) into user buffer.
>

I consider the IO context should be stored in the dataset as member
variables by the driver. I don't see a pressing reason to support
multiple raster IO operations at the same time with the same dataset.
I think a similar operation could safely be utilized by creating 2 or
more datasets and invoke their rasterIO simultaneously.
In case if the user specifies a different buffer or image section in
RasterIO then the driver would return with an error or gracefully
initiate a new sequence to the server implicitly.


Best regards,

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

Re: [gdal-dev] RE: progressive rendering

[Tamas Szekeres]

2008/8/29 Even Rouault <[EMAIL PROTECTED]>:
> Tamas,
>
> The only thing that was in Adam's proposal and that I don't find in yours is
> that, when the RasterIO in async mode returns something valid, the user has
> no way to know which part of the buffer has been updated by the driver. Thus,
> it introduces some extra cost for progressive image display since you then
> need to resend the whole buffer to your display window (before the first
> call, you must initialize the buffer to some default value too).
>
> Question : do we expect that it is going to ruin performance and/or interest
> of progressive rendering ?
>

Yes, this might be a crucial point. I've been considering that it's
more convenient for the user to do the same thing in all rendering
phase as retrieving the whole image than updating only sub-regions. I
consider only rectangle regions would play a role in this case.

However I should somewhat retract my statement here because of one
reason in my mind. Actually we cannot cosider the user can use the
same buffer as the driver with respect to some of the SWIG bindings.
In the RasterIO interface implementations the bindings might copy the
buffers between the target language and the GDAL core. Therefore we
cannot consider the buffer as read-write during the rasterio read
operation. BTW currently we only have ReadRaster/WriteRaster exposed
to the SWIG API.

In conclusion I'm tending to take over what Adam is proposing, however
we should have an additional method (or the synchronous version of the
RasterIO itself) to copy the region at the SWIG API.
This extra copy seems to be inevitable to me, because currently the
user (and the SWIG interface) is not required to keep the buffer
passed to RasterIO permanently. The external LockBuffer/ReleaseBuffer
by this means could be handled at driver level.


> I agree that the driver implementation may not be multi-threaded. But it's
> just a choice of implementation from the driver writer. The LockBuffer() /
> UnlockBuffer() API doesn't necessarily imply that the driver must use an
> auxiliary thread. An empty implementation would do for a non multithreaded
> driver. It just makes it possible for the driver to update-in-place the user
> buffer without the need for an internal buffer.
> But... I agree that the need for the LockBuffer()/UnlockBuffer() API is
> arguable since you need the 3 following conditions to be met for it to be
> really usefull :
> - a multi-threaded driver
> - AND it does not use a temporary buffer
> - AND the user doesn't lock for too long an area of the buffer that is going
> to be updated by the driver, otherwise the thread of the driver will be
> stalled by the mutex on the buffer.
> All other cases do not need that API.
>
> We could also imagine that the API exists but that the documentation of the
> driver explicitely says whether it is necessary to explictely Lock() /
> Unlock() the buffer, depending on how it is implemented.
>

This kind of stuff may lead to various kind of potential issues,
likewise I recall the introduction of of the smart pointers in the COM
world in order to avoid the mistakes when using AddRef, Release in the
right order.


> Hum, I'm thinking that --enable-threading must be explicitely passed to
> configure. So it means that a multi-threaded driver should be disabled if
> threading is not enabled. Maybe not a big deal but until now, no GDAL driver
> had this requirement.
>

Until this point GDAL could mainly avoid to trigger multiple threads
pretty well. I think only the warping code use threads at all.
Therefore using this global setting may affect quite unrelated parts
in GDAL which may be disadvantageous. By any means the multithreaded
behaviour of a driver should be kept internal as much as we can.


Best regards,

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

Re: [gdal-dev] RE: progressive rendering

[Tamas Szekeres]

2008/8/29 Adam Nowacki <[EMAIL PROTECTED]>:
>
> Im trying to design a interface with lowest overhead possible. Driver doesnt
> have to keep its own buffer and later copy, received data can be directly
> dumped into user buffer.
>

Adam,

As I have noted in the previous post we cannot easily consider this
"direct" manner realizable, because many of the SWIG wrappers may have
to copy the buffers between the target language and the GDAL core. To
mimic this behaviour of the interface would require to keep the buffer
at the API level which is almost equivalent as handling this at driver
level.

>
> The RasterIO function has been there for years. Changing its behavior by
> some hidden variable will definitely make it easier to use (or read) it the
> wrong way. Im trying to protect programmer's foots :)
>

The behaviour wouldn't change accidentally only upon the user's
explicit request.

>
> Being able to mix both blocking and async RasterIO calls sure would help to
> 'progressively' upgrade code from RasterIO to AsyncRasterIO.
> Opening 2 datasets would be a real bad thing: no shared cache.
>

Would the user be able to use both of the methods at the same time in
the original proposal?


>> I consider the IO context should be stored in the dataset as member
>> variables by the driver. I don't see a pressing reason to support
>> multiple raster IO operations at the same time with the same dataset.
>> I think a similar operation could safely be utilized by creating 2 or
>> more datasets and invoke their rasterIO simultaneously.
>> In case if the user specifies a different buffer or image section in
>> RasterIO then the driver would return with an error or gracefully
>> initiate a new sequence to the server implicitly.
>
> Consider a simple image browsing app with a overview box in a corner. Having
> 2 simultaneously running asynchronous raster io operations on the same
> dataset would allow the driver to optimize requests to the server possibly
> even eliminating separate requests for the overview. Or after zooming in the
> previously cached data for main view could be used to service the overview
> view.
>

Hmmm. It's quite difficult to imagine how the driver would operate to
achieve this. I don't think if it's equal to copy (and resample) a
region of a larger image than requesting the same region at the server
in many cases. The subsequent user requests would less likely require
the subset of an image in the same resolution and scale.

Best regards,

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

Re: [gdal-dev] Extending csharp binding for resampling

[Tamas Szekeres]

Marc,

Wouldn't it be sufficient to create a warped vrt dataset either by
opening the corresponding xml file or using the AutoCreateWarpedVRT
API?
Then you might want to use ReadRaster on that dataset so as to load
the stuff into an in-memory buffer.

Currently there's no native way to access the warp operations from the
SWIG interface.

Best regards,

Tamas



2008/8/29 Marc Jacquin <[EMAIL PROTECTED]>:
> Hi Gdal folks,
>
> Let's say we would like to use GDAL warping capabilities for resampling a
> dataset (without saving it on a file) at specific xcell and ycell with a
> specific resampling method but in Csharp. What would be the best way to do
> it?
> Let me guess:
> - First maintain our own Gdal build (that's fine)
> - Add the corresponding swig code to some .i files in the swig include
> directory
> - recompile the whole swig csharp stuff
>
> OK, but I'm not familiar with swig. Has anybody some swig code similar on
> the shelf? Wouldn't it be something useful to add to the official Gdal
> release?
>
> Regards,
>
> Marc Jacquin
> +(33) 562 247 023
> [EMAIL PROTECTED]
>
> Magellium
> 24, rue Hermès
> BP 12113
> 31521 RAMONVILLE Saint-Agne cedex
> France
> Phone: +(33) 562 247 000
> Fax: +(33) 562 247 001
>
>
> ___
> 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] RE: progressive rendering

[Tamas Szekeres]

Hi All,


Upon thinking about the issues I've been come up with previously, I
consider the following approach could be implemented easily either at
driver or at SWIG interface level. Requires a new class to be
implemented by the async IO supported drivers and a new additional
method should be added to the GDALDataset and GDALRasterBand.
The user could implement the async IO by using the following pseudo sequence:



GDALDataset *ds = GDALOpen( name, Access.GA_ReadOnly );

// create an IO context for the asynchronous operation
// the diver will initiate the transfer from the server and set:
ctx->status to IO_PENDING
// the diver will store the internal state of the transfer in the ctx object.
// GDALRasterBand may also implement the similar method by using the
proper arguments.
GDALRasterIOContext *ctx = ds->CreateRasterIOContext(GF_Read, xOff,
yOff, xSize, ySize, buf_xSize, buf_ySize,
   buf_dataType, bandCount, bandMap, pixelSpace, lineSpace, bandSpace);

while (ctx->status != IO_COMPLETE)
{
// Update the buffer with the next stage of data. The driver is allowed to
// modify the buffer within ReadNextBlock only.
// ReadNextBlock will wait until the next displayable stage will arrive.
ctx->ReadNextBlock(buffer);

// update the view by using ctx->xOff, ctx->yOff, ctx->xSize, ctx->ySize



// the user have pressed the cancel button in the user interface thread.
if (bCancel)
{
// the driver will close the transfer from the server
ctx->CancelIO();
break;
}
}

// The GDALRasterIOContext destructor will close the transfer if needed




Best regards,

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

Re: [gdal-dev] OCI driver and Heap Corruption under Visual C++

[Tamas Szekeres]

Mateusz,

I could only mention http://trac.osgeo.org/gdal/ticket/2230 in this
topic but I'm not sure if it is related to this problem.
I have been using OCI compiled with MSVC2005 a couple of months ago,
but didn't find such issue. However I'm using /MD instead of /MDd most
of the time.

Best regards,

Tamas



2008/8/30 Mateusz Loskot <[EMAIL PROTECTED]>:
> Folks,
>
> I'm experiencing heap corruption while calling OCIEnvCreate [1] function
> from OCI library. I build OCI driver in debug mode (with flags /D_DEBUG
> /MDd) using Visual C++ 8.0 linking against Oracle 10g Client.
>
> The bug seems to be random, because first test I made was with minimal set
> of OGR drivers built-in. In this case OGR drivers registration failed with
> heap corruption error, precisely while deallocating string in this line [2].
> Next, I built GDAL with default set of drivers + OCI driver
> and in that case OCIEnvCreate causes heap corruption.
>
> I spent a couple of hours debugging this issue, playing with MSVC Crt
> debugging utils, using memory checkpoints, etc. but without any reasonable
> findings, so far.
>
> I'm interested in finding what causes this problem, so I'd be thankful if
> anyone who has experienced similar problem could report what/how/when/etc.
> here on the list, including version of Visual C++ compiler and compilation
> flags used.
>
>
> [1]
> http://trac.osgeo.org/gdal/browser/trunk/gdal/ogr/ogrsf_frmts/oci/ogrocisession.cpp#L113
>
> [2]
> http://trac.osgeo.org/gdal/browser/trunk/gdal/port/cpl_vsil_win32.cpp#L496
>
> Best regards,
> --
> Mateusz Loskot, http://mateusz.loskot.net
> Charter Member of OSGeo, http://osgeo.org
> ___
> 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] OCI driver and Heap Corruption under Visual C++

[Tamas Szekeres]

Mateusz,

I gave up monkeying with MDd after spending a couple of days to
eliminate these strange effects caused crashes in the windows builders
at the buildbot. My suspicion is that in this case we inevitably use
dll dependencies with different CRT setting may lead to unpredicted
problems (OCI lib might have been compiled with /MD I think). I guess
if you could compile all of the related dll with /MDd setting you
would probably gain a more stable debug package then, however I
consider we less likely need to debug into the CRT libraries itself,
so this is what you shouln't worry about. Sleep well :-)

Best regards,

Tamas



2008/8/30 Mateusz Loskot <[EMAIL PROTECTED]>:
> Tamas Szekeres wrote:
>>
>> Mateusz,
>>
>> I could only mention http://trac.osgeo.org/gdal/ticket/2230 in this
>> topic but I'm not sure if it is related to this problem.
>> I have been using OCI compiled with MSVC2005 a couple of months ago,
>> but didn't find such issue. However I'm using /MD instead of /MDd most
>> of the time.
>
> Tamas,
>
> Thanks for reminding me this ticket.
> Yes, indeed it seems to be related.
> However, as we are not linking against /MDd I suppose I shouldn't waste time
> on fixing it, though I'm not sure if I can't sleep well knowing GDAL might
> crash  ;-)
>
> Best regards,
> --
> Mateusz Loskot, http://mateusz.loskot.net
> Charter Member of OSGeo, http://osgeo.org
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] OCI driver and Heap Corruption under Visual C++

[Tamas Szekeres]

2008/8/30 Mateusz Loskot <[EMAIL PROTECTED]>:
> Mixing /MD and /MT may lead to big problems.
>
> Hmm, looks like not solvable problem for OCI.
>

That's true. In this topic I can always point to the following
article, especially to the "MORE INFORMATION" section:

http://support.microsoft.com/kb/140584


But I'd mention that it highly depend on how those dll-s interact with
each other. Dll-s having properly isolated operations with respect to
the memory management may co-operate fairly well with different CRT
settings. However in my experience using the debug and non debug
version of the CRT libraries in parallel may cause further issues that
may not be enumerated as a possible reason in this article.
So I consider using /MT and /MD simultaneously is much better that
using /MD and /MDd in parallel. Lovely

Best regards,

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

Re: [gdal-dev] RE: progressive rendering

[Tamas Szekeres]

2008/9/3 Norman Barker <[EMAIL PROTECTED]>:
> Hi,
>
> I have updated the RFC
>
> http://trac.osgeo.org/gdal/wiki/rfc24_progressive_data_support
>
> To take in all of your comments, and I have added a comment about how
> this is a progressive format driver, but is no longer asynchronous, and
> I am not sure how it ever could be asynchronous within the driver since
> the methods block.  It moves the thread handling to the user, which is a
> fair trade-off over simplicity and abstracting some of the nastier
> features of the protocol implemented.
>

I guess there's no need to maintain both ReadNextBlock and RasterIO in
parallel only to choose the proper name for this function.
I don't see why this function may not be asynchronous in effect. I
consider the following operations would be implemented at driver level
within this function:

1. Waiting for the next data to arrive, return if the user specified
timeout have elapsed.
2. Update the user buffer and the iocontext according to the incoming
data. If the data is ready to be rendered, then return immediately
otherwise go to 1.


In this regard the user thread is only blocked until a new data will
arrive and the buffer contains valid data. When the caller then
renders the display, new data may also be received at the driver so
the next call to RasteIO may also return immediately. However - for
example - in an 2D interlaced progressive rendering the driver should
wait until the next turnaround of the image will arive completely
before returning to the caller, since it's not too convenient to allow
the user to render intermediary images that are not ready to display
in the screen.

I consider moving the thread handling to the user is more beneficial
than disadvantageous, since the user will have the freedom to choose
the proper threading mode for their application. The user will have
the freedom to spawn new threads if needed to call RasterIO, however I
don't think it'll required in most cases.

I don't think if the driver would be required to copy padding data
into the user buffer since the user will be notified about the update
region that should be copied over.


Best regards,

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

Re: [gdal-dev] RE: progressive rendering

[Tamas Szekeres]

2008/9/3 Norman Barker <[EMAIL PROTECTED]>:
>
> 
> It would be useful to maintain both ReadNextBlock and RasterIO in the
> case of JPIP, it can be advantageous (if the client can handle it) to
> call regions of a server image on tile boundaries -> ReadNextBlock, but
> in most cases I think RasterIO will be called.
>
> If you think it will just be easier to keep RasterIO then I am fine with
> that.
> 
>

Norman,

I don't see the difference between the functionality of ReadNextBlock
and RasterIO. I guess it was only a name change when Adam have renamed
my ReadnextBlock to RasterIO and I didn't object to it.
Can you explain a possible difference from the aspect of the JPIP driver.
I admit the rasterIO region have already determined when
CreateRasterIOContext have been called. I think we cannot safely
change these parameters within the same IO context.


>
> 
> In comparison to a callback function, I think this behaviour is
> synchronous, we are blocking until a timeout, and then calling again for
> another time period even if it returns immediately.  However this isn't
> a bad thing.
> 
>

I consider the blocking will occur until that time when a valid update
is ready to be rendered by the user. In the meantime the user won't
really be able to render anything so I guess waiting here is not a big
issue. However if you would support the user to do any other thing
within this thread, then implement to return immediately when the
timeout is set to 0. Then status= IO_PENDING will show that there's
nothing new can be found in the buffer and RasterIO should be called
again soon.

>
> I don't think if the driver would be required to copy padding data
> into the user buffer since the user will be notified about the update
> region that should be copied over.
>
> 
> In the case of JPIP (however unfortunate) the server is allowed to
> adjust the region of the image returned this may require some padding
> the requested client buffer.
>

Hmmm... That's difficult for me to follow. Won't it result in ugly
effects in the image display?


Best regards,

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

Re: [gdal-dev] RE: progressive rendering

[Tamas Szekeres]

ic GDALDataset *GDALAsyncDatasetOpen" can be
> used by GDALOpen(). The current GDALOpen method iterates on each DRIVER
> object and calls  pfnOpen() pointer function on it. It has only knowledge of
> the driver object, so it couldn't make any use of GDALAsyncDatasetOpen(). Do
> we need to open the dataset in a particular way for the progressive/async
> rendering ? Can't arguments just be provided as the dataset name. Currently
> most drivers opening datasets that are not real files have a syntax
> like "DRIVER_NAME:host=X:dbname=X:user=:". This could be a way of
> initiating async io mode if necessary. Or maybe the papszOptions should be
> used at the CreateRasterIOContext() level. That's a convenient way of
> extending stuff, but we should avoid abusing it too... I guess your knowledge
> and experience of JPIP can guide the choice. My feeling is that it would be
> more appropriate to add it into CreateRasterIOContext(), as this will define
> a new transaction with the server. It seems unlikely that we would need to
> change the parameters of this transaction during it. This is just an
> intuition.
>
> 
> GDALAsyncDatasetOpen is called at the dataset level to open a session to the 
> JPIP server and gets all the image metadata etc - this metadata is required 
> before CreateRasterIOContext is called.
> 
>
> - I don't understand how SetView() interacts with the corresponding parameters
> in the initial CreateRasterIOContext().
>
> 
> The view and resolution will change a lot during the session initiated in the 
> GDALAsyncDatasetOpen since the data streamed is interactive with the user 
> input.  Currently SetView works for the currently set resolution level in 
> CreateRasterIOContext, I have just updated the code on the wiki to allow 
> setting the window level (resolution) as well with SetView rather than having 
> to create a new context.
> 
> - Really detail question... but when and by whom is the GDALRasterIOContext *
> freed ? I think one of my proposal was to add a symetrical method to
> CreateRasterIOContext. Something like
> "void the_good_class_name::DeleteRasterIOContext(GDALRasterIOContext *);" Then
> CancelIO() would be unnecessary.
>
>
> 
> Thanks for that one, Garbage Collectors in Java spoiled me!
>
> I think CancelIO may still be necessary to implement pauses and resumes to 
> the server from user.
>
> I have added clean up for the contexts to the wiki.
> 
>
> - Do we really need the GDALAsyncRasterBand class or corresponding
> functionnality ? My feeling is that we don't need it. If the user is only
> interested by one band, he can do that with the CreateRasterIOContext() at
> the dataset level.
>
> 
> It is there for completeness at the moment, after comments from Tamas.  I 
> agree that it is perhaps redundant with the new design, at the 
> CreateRasterIOContext level the bands are specified.
> 
>
> Even
>
> Le Wednesday 03 September 2008 19:24:40 Norman Barker, vous avez écrit :
>> Hi Tamas,
>>
>> Comments inline, thanks again for your thoughts.
>>
>> -Original Message-
>> From: Tamas Szekeres [mailto:[EMAIL PROTECTED]
>> Sent: Wednesday, September 03, 2008 10:59 AM
>> To: Norman Barker
>> Cc: gdal-dev@lists.osgeo.org
>> Subject: Re: [gdal-dev] RE: progressive rendering
>>
>> 2008/9/3 Norman Barker <[EMAIL PROTECTED]>:
>> > 
>> > It would be useful to maintain both ReadNextBlock and RasterIO in the
>> > case of JPIP, it can be advantageous (if the client can handle it) to
>> > call regions of a server image on tile boundaries -> ReadNextBlock,
>>
>> but
>>
>> > in most cases I think RasterIO will be called.
>> >
>> > If you think it will just be easier to keep RasterIO then I am fine
>>
>> with
>>
>> > that.
>> > 
>>
>> Norman,
>>
>> I don't see the difference between the functionality of ReadNextBlock
>> and RasterIO. I guess it was only a name change when Adam have renamed
>> my ReadnextBlock to RasterIO and I didn't object to it.
>> Can you explain a possible difference from the aspect of the JPIP
>> driver.
>> I admit the rasterIO region have already determined when
>> CreateRasterIOContext have been called. I think we cannot safely
>> change these parameters within the same IO context.
>>
>> 
>> Isn't there a function in GDAL to get the most appropriate block size,
>> it will certainly be possible to advertise this through JPIP. Whereas
>> with RasterIO you could specify a region that covers many blocks.  Again
>> I d

Re: [gdal-dev] RE: progressive rendering

[Tamas Szekeres]

Just another note UpdateDisplay should go into the while loop in order
to render the itermediary stages in the sample code, like:

while (ctx-> status != IO_COMPLETE)
   {

 ctx->RasterIO(buffer, options);

 UpdateDisplay(buffer);

  // check has the view updated, is the request cancelled
  if (bCancel || viewChanged)
  {
 update = false;
 ctx -> CancelIO();
 break;
  }
   }



2008/9/5 Tamas Szekeres <[EMAIL PROTECTED]>:
> Norman,
>
> I'd require at least one more roundtrip to reach the final form before
> placing a vote on this. I'm afraid not all of the comments have been
> taken into account and this one seems more complicated that in could
> eventually be.
>
> 1. I don't see introducing a new AsyncDataSet call would be more
> beneficial than disadvantageous here. It would require some further
> action for the user at the C API to decide whether a DataSet supports
> this new interface or not. You should refer to GDALOpen which returns
> a generic DataSet class to the caller.
> I think it's not too bad to allow to implement CreateRasterIO context
> for the exising datasets as well. IMO we should simply add
> CreateRasterIOContext to the current GDALDataSet class.
>
> 2. I'm hesitant to think that adding this SetView method is necessary,
> why should we change the raster window within the same iocontext at
> all. Is it unconfortable to create a new context in case it the view
> is changing?
>
> 3. I still see the deprecated ReadNextBlock still exists in the proposal.
>
> 4. It seems unreasonable to add DeleteContext as a new method to the
> dataset. Why don't we delete the context object itself? The destructor
> could call the CancelIO implicitly if needed. With regard to the
> garbage collected SWIG bindings like Java and C# they all support a
> deterministic finalizer method like finalize(), delete() or Dispose()
> to allow the user to clear the things up manually if needed.
> We could eventually keep CancelIO however, in order to make sure that
> the operation was successfully canceled o not, by setting the state of
> the IO accordingly.
>
> By considering these I think it would be in a good shape to start
> creating a reference implementation around the concept. I think we all
> have some doubts that a real implementation wouldn't bring in further
> things that haven't been addressed yet in this RFC.
>
> Best regards,
>
> Tamas
>
>
>
> 2008/9/4 Norman Barker <[EMAIL PROTECTED]>:
>> Hi Even,
>>
>> Firstly, Tamas is right ReadBlock, RasterIO are identical - stupid mistake 
>> on my part :-) - a user can still optimize the remote reading by picking the 
>> correct view to match the image metadata from the server (if they so wish).
>>
>> Comments inline and I have also updated the wiki.
>>
>> I would like to propose this for a vote, where we are voting to approve the 
>> interface for submission into GDAL pending an implementation.  I have 
>> initial approval (as in from my employer) to do the implementation - also I 
>> am contacting other jpip vendors to make sure we get an interoperable 
>> driver; we will of course be testing against kakadu as well.  I wish to get 
>> the interface approved before proceeding to code the engine.
>>
>> Comments as always appreciated, apologies if I have not done the vote part 
>> correctly - it of course has a +1 from me!
>>
>> My comments inline below;
>>
>> -Original Message-
>> From: Even Rouault [mailto:[EMAIL PROTECTED]
>> Sent: Wednesday, September 03, 2008 4:42 PM
>> To: Norman Barker
>> Cc: gdal-dev@lists.osgeo.org
>> Subject: Re: [gdal-dev] RE: progressive rendering
>>
>> Norman,
>>
>> just a very quick review of the latest state of the RFC after a quick reading
>> of it...
>>
>> - do we really need to make new classes GDALAsyncDataset and
>> GDALAsyncRasterBand. I've raised that point on previous email. --> potential
>> problem for the corresponding C API, but, I agree, not critical. We just need
>> to be aware of it.
>>
>> 
>> I agree with your comments about the C API, by making GDALAsyncDataset and 
>> GDALAsyncRasterBand it just makes the code base cleaner.  I am 50:50 on 
>> which way to go.  Am I right in thinking that if we added the virtual 
>> methods to GDALDataset then we could still have the same methods declared as 
>> virtual on GDALASyncXxxx and everything would work the same?  If so I 
>> propose we go as we are, and add the virtual methods later if required for 
>> the C API.
>> 
>>
>> - if we allow cl

Re: [gdal-dev] importFromMICoordSys function

[Tamas Szekeres]

It haven't been exposed to the SWIG API yet.

Best regards,

Tamas


2008/9/16 Darius <[EMAIL PROTECTED]>:
> Hi,
> is this function currently supported in OGR library?
> When I'm trying to call it, I'm getting this error (C# in VS 2003):
> 'OSGeo.OGR.SpatialReference' does not contain a definition for
> 'importFromMICoordSys'.
> I'm missing some additional references? Everything else works fine
> (all standart Ogr library
> functions).
>
>
> Thanks
> ___
> 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