Re: [gdal-dev] Motion: Adopt GDAL 3.7.2RC1 as 3.7.2 release

[Tamas Szekeres]

+1
Tamas

Even Rouault  ezt írta (időpont: 2023. szept.
7., Cs, 22:44):

> Hi,
>
> Motion:
>
> Adopt GDAL 3.7.2RC1 as 3.7.2 release
>
> Starting with my +1
>
> Even
>
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
>
> ___
> 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] Off-topic: speaking of viewsheds....

[Tamas Szekeres]

That looks very nice.

Best regards,

Tamas


Scott  ezt írta (időpont: 2023. júl. 7., P, 21:28):

> The following viewsheds were created with GDAL, one tif for every tenth
> of a mile along the 2,650 mile Pacific Crest Trail. Stitched together
> with ffmpeg:
>
> https://youtu.be/tmY27ZIVfpA
>
>
> On 7/7/23 12:17, Tamas Szekeres wrote:
> > Benoît,
> >
> > As far a I can understand - depending on the elevation model actually
> > used - you may get different results when changing the observer and the
> > target height or the observer location. I'm not sure how it would be
> > different if you set the target height specifically to the observer and
> > the observer height to the target height.
> >
> > Best regards,
> >
> > Tamas
> >
> >
> >
> >
> > Benoît DesRochers  > <mailto:benoit.desroche...@usherbrooke.ca>> ezt írta (időpont: 2023.
> > júl. 7., P, 19:21):
> >
> > Hello there,
> >
> > Long story short, I'm trying to generate a viewshed for every cell
> > in a raster and add them all up to get a new raster that would
> > represent how many pixels can be seen from every cell. It takes a
> > while, but it works!
> >
> > The problem is that I'm using non-default observer and target height
> > values (2m observer and 0.5m target) and the results are
> > significantly different when I invert them (Use the target height as
> > the observer and the observer as the target height). From what I
> > understand, most viewshed algorithms don't compute sightlines for
> > every cell but use a reference plane instead and I'm thinking that
> > might be where the problem comes from but I'm not sure.
> >
> > Am I doing something wrong or is that an expected outcome?
> >
> > Thanks,
> > Benoît
> > ___
> > gdal-dev mailing list
> > gdal-dev@lists.osgeo.org <mailto:gdal-dev@lists.osgeo.org>
> > https://lists.osgeo.org/mailman/listinfo/gdal-dev
> > <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
> ___
> 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] Viewshed potential issue?

[Tamas Szekeres]

Benoît,

As far a I can understand - depending on the elevation model actually used
- you may get different results when changing the observer and the target
height or the observer location. I'm not sure how it would be different if
you set the target height specifically to the observer and the observer
height to the target height.

Best regards,

Tamas




Benoît DesRochers  ezt írta (időpont:
2023. júl. 7., P, 19:21):

> Hello there,
>
> Long story short, I'm trying to generate a viewshed for every cell in a
> raster and add them all up to get a new raster that would represent how
> many pixels can be seen from every cell. It takes a while, but it works!
>
> The problem is that I'm using non-default observer and target height
> values (2m observer and 0.5m target) and the results are significantly
> different when I invert them (Use the target height as the observer and the
> observer as the target height). From what I understand, most viewshed
> algorithms don't compute sightlines for every cell but use a reference
> plane instead and I'm thinking that might be where the problem comes from
> but I'm not sure.
>
> Am I doing something wrong or is that an expected outcome?
>
> Thanks,
> Benoît
> ___
> 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

[gdal-dev] Reading ESRI .tpkx files

[Tamas Szekeres]

Hi,

Is that possible to read ESRI .tpkx files in GDAL? As far as I see the
closest driver for this format is ESRIC which can read "Esri Compact Cache
V2" but it requires a conf.xml file, which is not included in the tpkx
format .

Thanks,

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

Re: [gdal-dev] Total Viewshed and GDAL

[Tamas Szekeres]

Luis,

I'm interested in testing such algorithm, is that code publicly available?

Best regards,

Tamas


Luis Felipe Romero  ezt írta (időpont: 2023. ápr. 18., K,
7:15):

> Dear gdal-dev group members,
>
> I hope this email finds you well. I am Luis Felipe Romero, a researcher
> from the University of Malaga in Spain, and I am excited to introduce
> myself to this community. My research focuses on algorithms for digital
> elevation models (DEM), and in particular, the development of algorithms
> for the calculation of the total viewshed.
>
> Recently, my team has developed a highly efficient algorithm that can
> calculate the total viewshed for a model of 2500x2500 points in just 4
> seconds on a GPU or approximately 2 minutes on a 16-core CPU. Our algorithm
> is written in C++, and we also have a version that utilizes CUDA for GPU
> acceleration.
>
> I had a conversation with Even Roualt about the possibility of integrating
> our algorithm into GDAL. However, he informed me of the incompatibilities
> between GDAL and CUDA, but encouraged me to share my intentions with the
> group. Therefore, I would like to share our Total Viewshed approach with
> the gdal-dev community.
>
> Unlike Tamas Szekeres' Viewshed algorithm, our approach calculates the
> viewshed at all model points simultaneously by leveraging in-memory data
> alignment. While it may not be as efficient for calculating the viewshed of
> a small set of points, it is incredibly useful for determining the viewshed
> of an entire territory, such as for selecting the location of a cell phone
> tower or for forest surveillance path planning. Our algorithm can complete
> these types of calculations in a matter of minutes, as opposed to thousands
> of hours.
>
> My primary goal in reaching out to this group is to gain feedback and
> insights on how GDAL can be used to make our algorithms publicly accessible
> and even improved upon by the community. I believe that GDAL provides the
> necessary tools and interfaces to make this possible.
>
> I am currently in the process of familiarizing myself with the GDAL code
> structure, and it will take a few days before I can determine my first
> steps with it. Nevertheless, I am excited to contribute to this community
> and give visibility to our work.
>
> Thank you all in advance for your time and consideration.
>
> Best regards,
> ___
> 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] GDAL sponsored maintenance report: Aug 2021-March 2023

[Tamas Szekeres]

Hi Even,

Thank you for your hard work to keep GDAL running at a high intensity and
quality level, which also shows well in the openhub stats:

https://openhub.net/p/gdal/contributors?sort=latest_commit_span=12+months

Keep up the good work :-)

Best regards,

Tamas




Even Rouault  ezt írta (időpont: 2023. márc.
27., H, 18:35):

> Hi,
>
> After more than one year and a half of benefiting from the GDAL sponsored
> maintenance program, it is time to share with the community what work has
> been accomplished thanks to that sponsorship.  It is quite hard to
> summarize, as the amount of tasks reaches 1800 for a total of 1313 hours.
> So lots of small tasks that make the daily reality of maintaining a project
> like GDAL.
>
> Their global repartition is the following one:
>
>-
>
>Bug fixing: 51% of actions, 55% of time spent (including 177 bug fixes
>related to issues found by oss-fuzz)
>-
>
>Enhancements: 5% of actions, 15% of time spent
>-
>
>CMake related work: 5% of actions, 10% of time spent
>-
>
>Review of contributions: 20% of actions, 5% of time spent
>-
>
>Release management: 2% of actions, 4% of time spent
>-
>
>Bug triaging and analysis (without corresponding bug fix): 8% of
>actions, 3% of time spent
>-
>
>Maintenance of continuous integration setup: 3% of actions and time
>spent
>-
>
>Code enhancements/cleanups: 2% of actions and time spent
>-
>
>Documentation: 1% of actions and time spent
>-
>
>Other activities: mailing list discussions, bug reports to other
>projects, meetings, etc.
>
>
> This work has benefited mostly to GDAL (80%), PROJ (15%), libtiff (2%),
> openjpeg (1%) and more marginally to other projects associated with GDAL
> such as Xerces-C, poppler, libgeotiff, cppcheck, netcdf, curl, libjxl and
> shapelib.
>
> The CMake related work has been a major item of work for the mid 2021 -
> beginning of 2022 period. I cannot overstate the importance of the initial
> contribution of this work made by Hiroshi Miura who brought most of the
> initial material. That said, without the sponsored maintenance program
> which helped polishing and making it production ready for all environments
> supported by GDAL, this would likely have remained a out-of-tree project. I
> believe most stakeholders (contributors and users, at least the ones who
> build from source) are very satisfied with this transition from the
> historic build systems to a unified and more modern one, with consistent
> option naming. Building on Windows is in particular much easier nowadays,
> in particular when leveraging dependencies from distributions like vcpkg or
> Conda Forge. For GDAL developers, the new build system offers integration
> with IDEs and solves long standing annoyances like missing header
> dependency rules for partial rebuilds.
>
> Although it doesn’t show up particularly in the above statistics, making
> sure that the continuous integration configurations remain “green” at all
> times is a constant source of attention. Given the number of environments
> tested and the number of dependencies of GDAL, there is hardly a week where
> some action is not needed in that area to make sure that the code builds
> and compiles cleanly, tests pass, etc. We can now track a few rolling
> distributions to detect as early as possible sources of incompatibilities
> with our dependencies, and act early: report issues to upstream if there
> are bugs, or do changes in our code & build scripts to take them into
> account.
>
> Making sure that code contributions from others are reviewed in a timely
> manner is important for the contributor experience. The average delay for a
> submitted pull request (excluding mine) to be commented by me (or merged if
> no comment needed) is 22 hours, and the median time 3h20 (statistics
> gathered on 601 pull requests since August 2021, source script at
> https://gist.github.com/rouault/0fbd37f59b8e93ae63761468a5600262)
>
> In the category of regular tasks, one can also mention: updating the EPSG
> dataset in PROJ (and coordinating with IOGP when detecting issues),
> refreshing vendored of copies in the GDAL source tree (libtiff typically),
> making sure that new SQLite releases play nicely with PROJ which has some
> stressing SQL queries (we spot recently a performance regression in SQLite
> 3.41.0 and reported it to upstream)
>
> The following RFCs have been implemented (not mentioning a few procedural
> ones) thanks to the sponsorship:
>
>-
>
>RFC 87: Signed int8 data type for raster
>
>-
>
>RFC 88: Use GoogleTest framework for C/C++ unit tests
>
>-
>
>RFC 90: Direct access to compressed raster data
>
>-
>
>RFC 91: GDALDataset::Close() method
>

Re: [gdal-dev] Motion: Adopt GDAL 3.6.3RC1 as 3.6.3 release

[Tamas Szekeres]

+1

Tamas

Even Rouault  ezt írta (időpont: 2023. márc.
9., Cs, 16:41):

> Same motion, just fixing the title to reflect the correction version
> number, as kindly pointed out.
>
> Le 09/03/2023 à 16:33, Even Rouault a écrit :
> > Hi,
> >
> > Motion:
> >
> > Adopt GDAL 3.6.3RC1 as 3.6.3 release
> >
> > Starting with my +1
> >
> > Even
> >
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
>
> ___
> 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] MSSQLSpatial driver cmake build issues

[Tamas Szekeres]

Even,

It looks like a good idea.

Thanks,

Tamas



Even Rouault  ezt írta (időpont: 2023. febr.
6., H, 21:13):

> Tamas,
>
> I would just do:
>
> - do a GDAL build with the MSSQLSpatial driver built-in with the generic
> ODBC driver: -DOGR_ENABLE_DRIVER_MSSQLSPATIAL_PLUGIN=OFF
> -DGDAL_USE_MSSQL_ODBC=OFF -DGDAL_USE_MSSQL_NCLI=OFF
>
> - build it as plugin with MSSQL_ODBC: run cmake again with
> -DOGR_ENABLE_DRIVER_MSSQLSPATIAL_PLUGIN=ON -DGDAL_USE_MSSQL_ODBC=ON
> -DGDAL_USE_MSSQL_NCLI=OFF
>
> - build it as plugin with MSSQL_NCLI: run cmake again with
> -DOGR_ENABLE_DRIVER_MSSQLSPATIAL_PLUGIN=ON -DGDAL_USE_MSSQL_ODBC=OFF
> -DGDAL_USE_MSSQL_NCLI=ON
>
> Even
> Le 06/02/2023 à 20:44, Tamas Szekeres a écrit :
>
> Hi GDAL Devs,
>
> The GISInternals build SDK has been changed to use GDAL 3.6.x and
> therefore it has completely switched to the cmake build. We noticed that
> this change caused to break the appveyor builds for MapServer (with the
> error: Unable to find driver `MSSQLSpatial' ).
> Formerly the MSQLSpatial driver has been built into GDAL by default using
> the legacy ODBC driver, but we could also compile plugin builds against the 
> *SQL
> Server Native Client* and the new *SQL Server ODBC 17* driver, too. If
> either of the plugins was installed with GDAL, the plugin driver (with the
> same name) superseded the functionality of the built in driver.
> With the cmake build - however - if we compile a plugin build (and only
> one driver is supported) the built in driver is not compiled anymore.
>
> The problem with the current solution is that neither the native client
> nor the ODBC 17 drivers are installed on Windows by default and these
> drivers require additional installations. When we install these plugins
> with GDAL, it may cause a failure when the driver is loaded that the the
> related ODBC driver dll-s couldn't be found on the system.
>
> Would that be possible somehow to restore the original behavior for
> example by modifying the cmake build setup for MSSQLSpatial, so that we
> could create a built-in driver as well as one or more plugin drivers
> (against different ODBC drivers) within the same cmake configuration? I
> guess it would somewhat require to add multiple *add_library* entries in
> the cmake setup, but I'm not sure how that fits into the current
> *add_gdal_driver* ecosystem.
>
>
> Thanks,
>
> Tamas
>
>
>
>
>
>
> ___
> gdal-dev mailing 
> listgdal-dev@lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> -- http://www.spatialys.com
> My software is free, but my time generally not.
>
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] MSSQLSpatial driver cmake build issues

[Tamas Szekeres]

Hi GDAL Devs,

The GISInternals build SDK has been changed to use GDAL 3.6.x and therefore
it has completely switched to the cmake build. We noticed that this change
caused to break the appveyor builds for MapServer (with the error: Unable
to find driver `MSSQLSpatial' ).
Formerly the MSQLSpatial driver has been built into GDAL by default using
the legacy ODBC driver, but we could also compile plugin builds
against the *SQL
Server Native Client* and the new *SQL Server ODBC 17* driver, too. If
either of the plugins was installed with GDAL, the plugin driver (with the
same name) superseded the functionality of the built in driver.
With the cmake build - however - if we compile a plugin build (and only one
driver is supported) the built in driver is not compiled anymore.

The problem with the current solution is that neither the native client nor
the ODBC 17 drivers are installed on Windows by default and these drivers
require additional installations. When we install these plugins with GDAL,
it may cause a failure when the driver is loaded that the the related ODBC
driver dll-s couldn't be found on the system.

Would that be possible somehow to restore the original behavior for example
by modifying the cmake build setup for MSSQLSpatial, so that we could
create a built-in driver as well as one or more plugin drivers (against
different ODBC drivers) within the same cmake configuration? I guess it
would somewhat require to add multiple *add_library* entries in the cmake
setup, but I'm not sure how that fits into the current *add_gdal_driver*
ecosystem.


Thanks,

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

Re: [gdal-dev] Motion: adopt RFC89: SQL query logging callback

[Tamas Szekeres]

+1

Tamas


Even Rouault  ezt írta (időpont: 2022. dec.
20., K, 4:58):

> It would be great if a few other PSC members could cast their vote.
>
> Even
>
> Le 15/12/2022 à 23:38, Even Rouault a écrit :
> > +1 Even
> >
> > Le 12/12/2022 à 15:10, ElPaso a écrit :
> >> Hi,
> >>
> >> Motion:
> >>
> >> Adopt  RFC89: SQL query logging callback [1]
> >>
> >> A draft implementation is available at [2].
> >>
> >> An example of how client code could make use of this new
> >> functionality is avaiable for QGIS at [3].
> >>
> >> Kind regards.
> >>
> >>
> >> [1] https://github.com/OSGeo/gdal/pull/6837
> >>
> >> [2]
> >>
> https://github.com/elpaso/gdal/tree/rfc89_sql_logging_callback_implementation
> >>
> >> [3] https://github.com/elpaso/QGIS/tree/ogrprovider-sql-logging
> >>
> >>
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
>
> ___
> 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] MSSQL Driver and Bulk Copy Drivers

[Tamas Szekeres]

Hi Seth,

The gdal nmake builds supports to build the mssql driver against MSODBC17,
by using these params in nmake.opt:

# Uncomment out the following to enable plugin with Microsoft ODBC Driver
17 for SQL Server support for MSSQL Bulk Copy.
#MSODBCSQL_VERSION = 17
#MSODBCSQL_DIR = C:\Program Files\Microsoft SQL Server\Client
SDK\ODBC\$(MSODBCSQL_VERSION)0\SDK
#MSODBCSQL_LIB =
"$(MSODBCSQL_DIR)\Lib\x86\msodbcsql$(MSODBCSQL_VERSION).lib"
#MSODBCSQL_INCLUDE = "-I$(MSODBCSQL_DIR)\Include"
-DMSODBCSQL_VERSION=$(MSODBCSQL_VERSION) -DMSSQL_BCP_SUPPORTED=1

I also think that the gisinternals builds have compiled the ODBC17 based
plugin earlier (looks like it is broken currently, I'll check that).

The recent cmake build can also be controlled in this regard by
the GDAL_USE_MSSQL_ODBC and GDAL_USE_MSSQL_NCLI parameters.

Best regards,

Tamas




Seth G  ezt írta (időpont: 2022. dec. 7., Sze,
15:21):

> Hi all,
>
> From the Microsoft docs at
> https://learn.microsoft.com/en-us/sql/relational-databases/native-client/applications/installing-sql-server-native-client?view=sql-server-ver16
> :
>
> > The SQL Server Native Client (often abbreviated SNAC) has been removed
> from SQL Server 2022 (16.x) and SQL Server Management Studio 19 (SSMS). The
> SQL Server Native Client (SQLNCLI or SQLNCLI11) and the legacy Microsoft
> OLE DB Provider for SQL Server (SQLOLEDB) are not recommended for new
> development. Switch to the new Microsoft OLE DB Driver (MSOLEDBSQL) for SQL
> Server or the latest Microsoft ODBC Driver for SQL Server going forward.
>
> So the native SQL Server driver will be retired, however the GDAL MSSQL
> Driver only supports bulk copy (BCP) with this driver and not the "ODBC
> Driver 17 for SQL Server" - the following error is returned:
>
> > ERROR 1: SQL Error SQLState=HY000, NativeError=0, Msg=[Microsoft][ODBC
> Driver 17 for SQL Server]Connection is not enabled for BCP
>
> According to
> https://learn.microsoft.com/en-us/sql/connect/odbc/microsoft-odbc-driver-for-sql-server?view=sql-server-ver16
> :
>
> > The ODBC driver comes with tools such as sqlcmd and bcp.
>
> Does anyone know if BCP can be enabled with the MS ODBC drivers?
>
> Thanks,
>
> Seth
>
>
>
> --
> web:https://geographika.net
> twitter: @geographika
> ___
> 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] Motion: Add Alessandro Pasotti as GDAL maintainer

[Tamas Szekeres]

+1

Tamas

Howard Butler  ezt írta (időpont: 2022. nov. 14., H, 16:45):

> Dear PSC,
>
> As a result of our fundraising activity and development of NumFOCUS as a
> financial conduit, it is my pleasure to put forward a motion to approve
> Alessandro Pasotti as a contracted GDAL maintainer for the period beginning
> on November 21st, 2022 and ending November 21st, 2023.
>
> Details of the maintenance tasking and duties can be found at the
> previously approved RFC 83
> https://gdal.org/development/rfc/rfc83_use_of_project_sponsorship.html
>
> The terms of the contract are for a maximum of 250 hours at 110 €/hr.
>
> Alessandro will plan to focus on GDAL tasks that make it easier to
> developer GUI applications like QGIS (of which he is also a very active
> contributor). This includes testing, APIs, and driver hardening.
>
> Howard
>
> PS I will coordinating the contracting activity in my role as the GDAL
> NumFOCUS contracting liaison, with Frank Warmerdam acting as the secondary.
> Please contact us directly with any comments or concerns.
> ___
> 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] Motion: Approve Even Rouault as a contracted GDAL maintainer for 2022-2023

[Tamas Szekeres]

+1

Tamas

Howard Butler  ezt írta (időpont: 2022. aug. 27., Szo,
14:43):

> Dear PSC,
>
> It has come to my attention that Even's term as a GDAL Maintainer
> officially ended 31 JUL 2022. I propose that we extend him for another year
> from 01 AUG 2022 to 31 JUL 2023 under the previous terms and conditions.
>
> Although a small formality, we should make sure to keep a small bit of
> process around these things.
>
> /me starts with +1
>
> Howard
>
> PS, expect a GDAL Sponsorship Annual Report next week.
> ___
> 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] Motion: adopt GDAL 3.4.3 RC2

[Tamas Szekeres]

+1

Tamas

Even Rouault  ezt írta (időpont: 2022. máj. 1.,
V, 22:46):

> Hi,
>
> Motion:
>
> Adopt GDAL 3.4.3 RC2 as final 3.4.3 release
>
> Starting with my +1
>
> Even
>
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
>
> ___
> 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] Adding OSGEO4W and gisinternals docs in install doc?

[Tamas Szekeres]

Currently the refactor is used in the build system. That is now working for
quire some time so that it will be promoted to be the main branch.

Best regards,

Tamas


Even Rouault  ezt írta (időpont: 2022. febr.
17., Cs, 19:44):

>
> Le 17/02/2022 à 19:22, Tamas Szekeres a écrit :
>
> To be correct, the latest version of the build scripts (including the
> Makefile) are on the refactor branch:
>
> https://github.com/gisinternals/buildsystem/tree/refactor
>
> nice! I actually see
> https://github.com/gisinternals/buildsystem/blob/refactor/config.opt with
> the URLs of the upstream repositories, and the build commands in
> https://github.com/gisinternals/buildsystem/blob/refactor/Makefile
>
> Is the refactor branch the one used for the builds at gisinternals.com ?
> (said otherwise, why isn't it the master branch ?)
>
>
> Tamas Szekeres  ezt írta (időpont: 2022. febr. 17.,
> Cs, 19:19):
>
>> For gisinternals, the entire build including the dependencies is
>> controlled by a single Makefile
>> <https://github.com/gisinternals/buildsystem/blob/master/Makefile> which
>> controls the builds of the dependencies including how to obtain them from
>> the source repositories. The makefile also contains the necessary tweaks
>> that had to be applied in a dependency if that required for a successful
>> build.
>>
>> Best regards,
>>
>> Tamas
>>
>>
>> Even Rouault  ezt írta (időpont: 2022. febr.
>> 17., Cs, 17:29):
>>
>>> Thomas,
>>>
>>> One criterion currently for inclusion is: "In this section we list a
>>> number of the binary distributions of GDAL all of which should have
>>> fully reproducible open source build recipes."
>>>
>>> I've not evaluated what the current situation of OSGeo4W or gisinternals
>>> is regarding this, especially regarding all direct and indirect
>>> dependencies of GDAL (or course, that must stop at the compiler level
>>> when using Visual Studio). I believe nowadays OSGeo4W must be closer to
>>> that aim of having fully reproducible builds, but I'm not sure to which
>>> extent. For gisinternals I'm not sure. It was my impression that the
>>> build recipees for the dependencies were not available, but maybe I'm
>>> wrong. I'll let the developers of those distributions comment further if
>>> they wish.
>>>
>>> Even
>>>
>>> Le 17/02/2022 à 17:17, Thomas Gratier a écrit :
>>> > Hi,
>>> >
>>> > I regularly orient third parties to use GDAL utilities and for this
>>> > intent, point them to install section
>>> > https://gdal.org/download.html#binaries
>>> >
>>> > For Windows, I did not see a user friendly section about how to
>>> > install it. I want to mention in the doc how to install with OSGEO4W
>>> > and https://www.gisinternals.com/index.html
>>> > Opinions? If ok, I will do a PR later on the github repo
>>> >
>>> >
>>> > Regards
>>> >
>>> > Thomas Gratier
>>> >
>>> > ___
>>> > gdal-dev mailing list
>>> > gdal-dev@lists.osgeo.org
>>> > https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>>
>>> --
>>> http://www.spatialys.com
>>> My software is free, but my time generally not.
>>>
>>> -- http://www.spatialys.com
> My software is free, but my time generally not.
>
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Adding OSGEO4W and gisinternals docs in install doc?

[Tamas Szekeres]

To be correct, the latest version of the build scripts (including the
Makefile) are on the refactor branch:

https://github.com/gisinternals/buildsystem/tree/refactor

Tamas Szekeres  ezt írta (időpont: 2022. febr. 17.,
Cs, 19:19):

> For gisinternals, the entire build including the dependencies is
> controlled by a single Makefile
> <https://github.com/gisinternals/buildsystem/blob/master/Makefile> which
> controls the builds of the dependencies including how to obtain them from
> the source repositories. The makefile also contains the necessary tweaks
> that had to be applied in a dependency if that required for a successful
> build.
>
> Best regards,
>
> Tamas
>
>
> Even Rouault  ezt írta (időpont: 2022. febr.
> 17., Cs, 17:29):
>
>> Thomas,
>>
>> One criterion currently for inclusion is: "In this section we list a
>> number of the binary distributions of GDAL all of which should have
>> fully reproducible open source build recipes."
>>
>> I've not evaluated what the current situation of OSGeo4W or gisinternals
>> is regarding this, especially regarding all direct and indirect
>> dependencies of GDAL (or course, that must stop at the compiler level
>> when using Visual Studio). I believe nowadays OSGeo4W must be closer to
>> that aim of having fully reproducible builds, but I'm not sure to which
>> extent. For gisinternals I'm not sure. It was my impression that the
>> build recipees for the dependencies were not available, but maybe I'm
>> wrong. I'll let the developers of those distributions comment further if
>> they wish.
>>
>> Even
>>
>> Le 17/02/2022 à 17:17, Thomas Gratier a écrit :
>> > Hi,
>> >
>> > I regularly orient third parties to use GDAL utilities and for this
>> > intent, point them to install section
>> > https://gdal.org/download.html#binaries
>> >
>> > For Windows, I did not see a user friendly section about how to
>> > install it. I want to mention in the doc how to install with OSGEO4W
>> > and https://www.gisinternals.com/index.html
>> > Opinions? If ok, I will do a PR later on the github repo
>> >
>> >
>> > Regards
>> >
>> > Thomas Gratier
>> >
>> > ___
>> > gdal-dev mailing list
>> > gdal-dev@lists.osgeo.org
>> > https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>> --
>> http://www.spatialys.com
>> My software is free, but my time generally not.
>>
>>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Adding OSGEO4W and gisinternals docs in install doc?

[Tamas Szekeres]

For gisinternals, the entire build including the dependencies is controlled
by a single Makefile
 which
controls the builds of the dependencies including how to obtain them from
the source repositories. The makefile also contains the necessary tweaks
that had to be applied in a dependency if that required for a successful
build.

Best regards,

Tamas


Even Rouault  ezt írta (időpont: 2022. febr.
17., Cs, 17:29):

> Thomas,
>
> One criterion currently for inclusion is: "In this section we list a
> number of the binary distributions of GDAL all of which should have
> fully reproducible open source build recipes."
>
> I've not evaluated what the current situation of OSGeo4W or gisinternals
> is regarding this, especially regarding all direct and indirect
> dependencies of GDAL (or course, that must stop at the compiler level
> when using Visual Studio). I believe nowadays OSGeo4W must be closer to
> that aim of having fully reproducible builds, but I'm not sure to which
> extent. For gisinternals I'm not sure. It was my impression that the
> build recipees for the dependencies were not available, but maybe I'm
> wrong. I'll let the developers of those distributions comment further if
> they wish.
>
> Even
>
> Le 17/02/2022 à 17:17, Thomas Gratier a écrit :
> > Hi,
> >
> > I regularly orient third parties to use GDAL utilities and for this
> > intent, point them to install section
> > https://gdal.org/download.html#binaries
> >
> > For Windows, I did not see a user friendly section about how to
> > install it. I want to mention in the doc how to install with OSGEO4W
> > and https://www.gisinternals.com/index.html
> > Opinions? If ok, I will do a PR later on the github repo
> >
> >
> > Regards
> >
> > Thomas Gratier
> >
> > ___
> > gdal-dev mailing list
> > gdal-dev@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
>
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] [geos-devel] GEOS Maintenance Grant

[Tamas Szekeres]

+1

Tamas

Howard Butler  ezt írta (időpont: 2022. febr. 15., K,
16:37):

> GDAL PSC,
>
> When we wrote the GDAL RFCs on sponsorship, we provided an escape clause
> to allow us to direct resources to other projects upon which GDAL depends.
> Our sponsorship numbers are still increasing, which provides us an
> opportunity to directly support some of those projects, and one of them is
> obviously GEOS. GEOS provides all of the geometry algebra support for
> GDAL/OGR and many other open source geospatial softwares including Shapely,
> PostGIS, GeoPandas, MapServer, and more.
>
> Dan Baston of the GEOS PSC has been identified as the developer with
> capacity and interest in the next year to take on GEOS development on APIs
> and performance, which he has a long history of doing for the project. This
> support should allow him to work longer, multi-release upgrades that will
> provide strong performance and convenience benefits for the project.
>
> I motion to provide the GEOS PSC with a $50,000 USD grant to address
> performance, API, and other work that does not attract directed funding in
> GEOS. The GEOS PSC will be responsible for coordinating work tasks, rates,
> and development timelines. Howard Butler or Even Rouault of the GDAL
> NumFocus liaison team will coordinate dispersement as directed by the GEOS
> PSC and NumFocus rules.
>
> Thank you again to the GDAL Sponsors https://gdal.org/sponsors/index.html
> who have made this kind of grant possible. A better GEOS makes for a better
> GDAL.
>
> Howard
>
> ___
> geos-devel mailing list
> geos-de...@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion: grant github commit rights to Nyall Dawson

[Tamas Szekeres]

+1  Tamas

Even Rouault  ezt írta (időpont: 2022. jan.
26., Sze, 0:34):

> Hi,
>
> I'd like to motion to grant github commit rights to Nyall. We don't have
> much people currently doing reviews of pull requests and pressing the
> "Merge" button, and Nyall is definitely in a capacity of fulfilling this
> responsibility, at least in the areas where he fills comfortable. His
> own pull requests are of excellent quality and he's one of the few to
> review my work.
>
> Starting with my +1
>
> Even
>
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
>
> ___
> 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] Motion: adopt RFC 85: Policy regarding substantial code additions

[Tamas Szekeres]

+1

Tamas

Even Rouault  ezt írta (időpont: 2022. jan.
21., P, 11:18):

> Hi,
>
> As the discussion seems to have calmed down, I move to adopt RFC 85:
> Policy regarding substantial code additions:
> https://github.com/OSGeo/gdal/pull/5128
>
> Starting with my +1
>
> Even
>
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
>
> ___
> 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] Shortening schedule for CMake adoption ?

[Tamas Szekeres]

+1

I'll also do some checks in the next few weeks to make sure the things work
on Windows as expected.

Best regards,

Tamas


Even Rouault  ezt írta (időpont: 2022. jan.
17., H, 14:38):

> Hi,
>
> The new CMake build system
> (https://gdal.org/development/rfc/rfc84_cmake.html) has made excellent
> progress, and I believe that it should be in a production ready state on
> time for GDAL 3.5.0 (~ May). It is already very close to it according to
> a checklist I had created
> (
> https://docs.google.com/spreadsheets/d/1SsUXiZxKim6jhLjlJFCRs1zwMvNpbJbBMB6yl0ms01c).
>
> Consequently we could shorten the rather conservative schedule presented
> in RFC 84 to :
>
> - Formally deprecate GNUmakefile and NMake base file systems. Users and
> packagers are encouraged to switch to CMake and actively report (and
> help fixing) issues the find in the process.
>
> ==> Target: GDAL 3.5 / May 2022. GDAL 3.5.x point releases will be used
> to address reported issues.
>
> - Completely remove GNUmakefile and NMake base file systems, and make
> CMake the only build system in GDAL source tree.
>
> ==> Target: GDAL 3.6 / November 2022
>
>
> I can't see real advantages in keeping the 3 build systems longer than
> strictly needed:
>
> - it requires more maintenance effort and makes new contributions more
> complicated
>
> - we won't probably get significant feedback regarding the CMake build
> system until people have to adopt it because they have no other
> alternative.
>
> We already greatly welcome feedback from people trying with master. To
> facilitate this, I believe we could cut a GDAL 3.5 alpha in early March
> so that people who wait for "official" packages have a chance to give it
> a try too.
>
> Thoughts ?
>
> Even
>
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
>
> ___
> 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] Motion: Approve Nyall Dawson as a contracted GDAL maintainer

[Tamas Szekeres]

+1

Tamas

Howard Butler  ezt írta (időpont: 2021. szept. 14., K,
16:59):

> Dear PSC,
>
> As a result of our fundraising activity and development of NumFOCUS as a
> financial conduit, it is my pleasure to put forward a motion to approve
> Nyall Dawson as a contracted GDAL maintainer for the year 2021-2022
> beginning on October 1st, 2021 and ending September 30th, 2022.
>
> Details of the maintenance tasking and duties can be found at the
> previously approved RFC 83
> https://gdal.org/development/rfc/rfc83_use_of_project_sponsorship.html
>
> The terms of the contract are for a maximum of 500 hours at 90 €/hr.
>
> Howard
>
> PS I will coordinating the contracting activity in my role as the GDAL
> NumFOCUS contracting liaison, with Frank Warmerdam acting as the secondary.
> Please contact us directly with any comments or concerns.
> ___
> 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] Motion: promote GDAL 3.3.2 RC3

[Tamas Szekeres]

+1

Tamas

Sent from my iPhone

> 2021. szept. 2. dátummal, 8:56 időpontban Even Rouault 
>  írta:
> 
> Hi,
> 
> Having heard no issues being reported regarding RC3
> 
> Motion:
> 
> Adopt GDAL 3.3.2 RC3 as final 3.3.2 release
> 
> Starting with my +1
> 
> Even
> 
> -- 
> http://www.spatialys.com
> My software is free, but my time generally not.
> 
> ___
> 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] Motion: Approve Even Rouault as a contracted GDAL maintainer

[Tamas Szekeres]

+1

Tamas


> 2021. aug. 17. dátummal, 17:35 időpontban Howard Butler  írta:
> 
> Dear PSC,
> 
> As a result of our fundraising activity and development of NumFOCUS as a 
> financial conduit, it is my pleasure to put forward a motion to approve Even 
> Rouault as a contracted GDAL maintainer for the year 2021-2022 beginning on 
> August 1st, 2021 and ending July 31st, 2022. 
> 
> Details of the maintenance tasking and duties can be found at the previously 
> approved RFC 83 
> https://gdal.org/development/rfc/rfc83_use_of_project_sponsorship.html
> 
> The terms of the contract are for 833 hours at $120/hr USD.
> 
> Howard
> 
> PS I will coordinating the contracting activity in my role as the GDAL 
> NumFOCUS contracting liaison, with Frank Warmerdam acting as the secondary. 
> Please contact us directly with any comments or concerns.
> ___
> 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] Considering drivers removal ?

[Tamas Szekeres]

Hi Sean,

I would also be supportive to formalize the driver submission process.

Best regards,

Tamas


Sean Gillies  ezt írta (időpont: 2021. jan. 28., Cs,
17:39):

> Hi Tamas,
>
> Are you suggesting that a RFC be required for a new driver? I would
> support this 100%.
>
> On Wed, Jan 27, 2021 at 2:17 PM Tamas Szekeres 
> wrote:
>
>> David,
>>
>> Up to this time the driver writers were highly welcomed to author new
>> drivers for the project and these effort didn't require a separate RFC in
>> terms of the Project Management Committee Guidelines
>> <https://gdal.org/development/rfc/rfc1_pmc.html> document. Adding new
>> drivers hasn't been considered to be substantial changes or something that
>> causes to change the API or brings in backwards incompatibility issues.
>> However in a real deployment situation the drivers may cause issues for
>> the developers, end users and package maintainers from several aspects like
>> so:
>>
>> 1. The drivers may depend on external libraries and we don't want to link
>> against those libraries in all cases.
>> 2. The external libraries may cause license incompatibilities, ie linking
>> against that may change the license terms of the overall project.
>> 3. Not all of the drivers are required in a particular solution (that
>> applies to the built in drivers, too). In a real situation the application
>> may use only a limited set of drivers and the existence of the unwanted
>> drivers may cause some performance degradation.
>> 4. Implementing custom compilations (and omitting unwanted drivers from
>> the build) may be problematic for most of the users or projects utilizing
>> gdal as a sub-project.
>>
>> In my opinion, the current solution of incubating new drivers is fairly
>> minimalistic, we might probably want to know what kind of format is being
>> addressed, who is the audience, how amount of user might be of interest,
>> how the licensing of the dependent project is looking like, is the
>> dependent project (if any) maintained well enough and can be compiled to
>> each supported platforms etc.
>>
>> But replying to the question, I think you shoud continue the effort, but
>> consider to implement a plugin build for that. There are several existing
>> drivers are compiled as plugins at the moment, so it should not be so
>> difficult.
>>
>>
>> Best regards,
>>
>> Tamas
>>
>>
>> David Brochart  ezt írta (időpont: 2021. jan.
>> 27., Sze, 15:29):
>>
>>> I am currently trying to add a Zarr driver to GDAL (see
>>> https://github.com/OSGeo/gdal/pull/3411), but from what I can see the
>>> trend is to remove drivers, so I'm now wondering it I should pursue this
>>> effort. I'm relatively new to GDAL, but from my point of view supporting a
>>> lot of formats is part of GDAL's success, so maybe the real focus should be
>>> on implementing a plugin mechanism that would allow driver development
>>> independently from core GDAL. Again, I might not have enough background to
>>> give valuable feedback.
>>>
>>> Regards,
>>>
>>> David.
>>>
>>> On Wed, Jan 27, 2021 at 12:34 PM thomas bonfort <
>>> thomas.bonf...@gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On Tue, Jan 12, 2021 at 11:36 PM Even Rouault <
>>>> even.roua...@spatialys.com> wrote:
>>>>
>>>>>
>>>>> The issue with esoteric/legacy drivers is not that much maintenance of
>>>>> the
>>>>> actual code of the drivers, in the sense of dealing with bug reports,
>>>>> questions, etc. (pretty sure they are none for the ones I listed).
>>>>> Most of
>>>>> them must work reasonably well and be feature complete, and most
>>>>> vulnerabilities have now been fixed. My concern is that this legacy
>>>>> code has
>>>>> indirect costs on other GDAL developers and users. The psychological
>>>>> cost I
>>>>> mentionned. Let's say someone want to turn on higher warning levels,
>>>>> and that
>>>>> this breaks in tens of drivers. Would he have to ping every maintainer
>>>>> and
>>>>> wait for them to address the issue ? Or maybe he will just give up.
>>>>> Similarly
>>>>> for breaking changes in the driver API. As Sean mentionned, this is
>>>>> probably a
>>>>> serious obstacle to growing up the core development team.
>>>>>
>

Re: [gdal-dev] Considering drivers removal ?

[Tamas Szekeres]

David,

Up to this time the driver writers were highly welcomed to author new
drivers for the project and these effort didn't require a separate RFC in
terms of the Project Management Committee Guidelines
 document. Adding new
drivers hasn't been considered to be substantial changes or something that
causes to change the API or brings in backwards incompatibility issues.
However in a real deployment situation the drivers may cause issues for the
developers, end users and package maintainers from several aspects like so:

1. The drivers may depend on external libraries and we don't want to link
against those libraries in all cases.
2. The external libraries may cause license incompatibilities, ie linking
against that may change the license terms of the overall project.
3. Not all of the drivers are required in a particular solution (that
applies to the built in drivers, too). In a real situation the application
may use only a limited set of drivers and the existence of the unwanted
drivers may cause some performance degradation.
4. Implementing custom compilations (and omitting unwanted drivers from the
build) may be problematic for most of the users or projects utilizing gdal
as a sub-project.

In my opinion, the current solution of incubating new drivers is fairly
minimalistic, we might probably want to know what kind of format is being
addressed, who is the audience, how amount of user might be of interest,
how the licensing of the dependent project is looking like, is the
dependent project (if any) maintained well enough and can be compiled to
each supported platforms etc.

But replying to the question, I think you shoud continue the effort, but
consider to implement a plugin build for that. There are several existing
drivers are compiled as plugins at the moment, so it should not be so
difficult.


Best regards,

Tamas


David Brochart  ezt írta (időpont: 2021. jan.
27., Sze, 15:29):

> I am currently trying to add a Zarr driver to GDAL (see
> https://github.com/OSGeo/gdal/pull/3411), but from what I can see the
> trend is to remove drivers, so I'm now wondering it I should pursue this
> effort. I'm relatively new to GDAL, but from my point of view supporting a
> lot of formats is part of GDAL's success, so maybe the real focus should be
> on implementing a plugin mechanism that would allow driver development
> independently from core GDAL. Again, I might not have enough background to
> give valuable feedback.
>
> Regards,
>
> David.
>
> On Wed, Jan 27, 2021 at 12:34 PM thomas bonfort 
> wrote:
>
>>
>>
>> On Tue, Jan 12, 2021 at 11:36 PM Even Rouault 
>> wrote:
>>
>>>
>>> The issue with esoteric/legacy drivers is not that much maintenance of
>>> the
>>> actual code of the drivers, in the sense of dealing with bug reports,
>>> questions, etc. (pretty sure they are none for the ones I listed). Most
>>> of
>>> them must work reasonably well and be feature complete, and most
>>> vulnerabilities have now been fixed. My concern is that this legacy code
>>> has
>>> indirect costs on other GDAL developers and users. The psychological
>>> cost I
>>> mentionned. Let's say someone want to turn on higher warning levels, and
>>> that
>>> this breaks in tens of drivers. Would he have to ping every maintainer
>>> and
>>> wait for them to address the issue ? Or maybe he will just give up.
>>> Similarly
>>> for breaking changes in the driver API. As Sean mentionned, this is
>>> probably a
>>> serious obstacle to growing up the core development team.
>>>
>>
>> Given that we have a relatively easy way to disable individual drivers at
>> compile time, could we expand on this mechanism to mark problematic drivers
>> as "orphaned" in this case? The code would still live in the repo but would
>> be effectively disabled until someone with sufficient interest invests the
>> time/money to update the problematic code and re-enable it.
>> This will of course create some overhead to keep track of which drivers
>> have been orphaned from one release to the next, create github
>> issues/labels to list which drivers need work to be re-enabled, etc... But
>> it shifts the burden of maintaining the codebase of 250 drivers from the
>> core team over to the people/companies who actually need them. I'd be
>> willing to contribute the scripts that could ease the process of
>> orphaning/reintegrating a specific driver.
>>
>> Regards,
>> Thomas
>> ___
>> 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
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] How to convert GDAL Vector dataset to memory stream

[Tamas Szekeres]

Hi,

MVT is a vector format, so you should use OGR to manipulate it.
To open the OGR format and iterate the features on a layer refer to the
following c# example:

https://github.com/OSGeo/gdal/blob/master/gdal/swig/csharp/apps/ogrinfo.cs

Also refer to the MVT driver information page, how the connection string
should look like and which open options can be used.

https://gdal.org/drivers/vector/mvt.html

Best regards,

Tamas


MRRAJESH  ezt írta (időpont: 2020. jún. 21., V,
7:11):

> Hi Tamas,
>
> Thanks for your suggestions. Will it work for MVT memory dataset?
>
> We have an MVT memory dataset with us. How to convert this to memory
> stream.
>
> *Example: *
> .
> var vsibuf = string.Format(@"/vsimem/mvt");
> var newDs = Gdal.wrapper_GDALVectorTranslateDestName(vsibuf, ds1,
> gdalOptions, null, null);
> newDs.Dispose();
>
> string filePath = string.Format("{0}\\{1}\\{2}\\{3}.mvt", vsibuf, 18,
> 66027,
> 96262);
>
> We tried below ways:
>
> *Way1:*
>
> Dataset ds = Gdal.OpenEx(filePath, 0, null, open_options, null);
>
> How to convert a dataset (ds) to memory stream?
>
> *Way2:*
>
> var bufPtr = Gdal.VSIFOpenL(filePath, "rb");
> if (bufPtr != null)
> {
>   Gdal.VSIFSeekL(bufPtr, 0, 2); // seek to end
>   var contentSize = Gdal.VSIFTellL(bufPtr1);
>   Gdal.VSIFSeekL(bufPtr1, 0, 0); // seek to beginning
>   var data = new byte[contentSize];
>   var content = VSIFReadL(1, contentSize, bufPtr); // This method
> is
> not available in C#.
> }
>
> How to get content here?
>
> Regards,
> Rajesh
>
>
>
> --
> Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
> ___
> 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] How to convert GDAL Vector dataset to memory stream

[Tamas Szekeres]

Hi,

You could use a pre-allocated array to fill data from a GDAL dataset/bands.
The following examples could be used as a reference:

1. Read raster bands into separate byte arrays:

https://github.com/OSGeo/gdal/blob/master/gdal/swig/csharp/apps/GDALRead.cs#L139


 2. Read raster bands into bitmap data

https://github.com/OSGeo/gdal/blob/ecd7ed1420aa07691f88aca66ea8a13af38433f2/gdal/swig/csharp/apps/GDALReadDirect.cs#L140

3. Read dataset into bitmap data

https://github.com/OSGeo/gdal/blob/ecd7ed1420aa07691f88aca66ea8a13af38433f2/gdal/swig/csharp/apps/GDALDatasetRasterIO.cs#L116

Best regards,

Tamas



MRRAJESH  ezt írta (időpont: 2020. jún. 17., Sze,
18:39):

> Hello list,
>
> I'm using GDAL via swig C# bindings. Is there a way to create memory stream
> from gdal vector dataset. If so, how  can I achieve this.
>
> Thanks in advance
> Rajesh
>
>
>
>
> --
> Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
> ___
> 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] c# bindings - osr SpatialReference constructor

[Tamas Szekeres]

You should use null in the constructor if you don't want to specity a wkt
during the initialization, something like:


*SpatialReference srs = new
SpatialReference(null);srs.ImportFromEPSG(2927);*

Best regards,

Tamas



Paul Harwood  ezt írta (időpont: 2020. jún. 16., K,
19:01):

> A common pattern for creating a SpatialReference is this :
>
> from osgeo import osr
> spatialRef = osr.SpatialReference()
> spatialRef.ImportFromEPSG(2927) # from EPSG
>
> ( this example is from the Python Cookbook and is just used to illustrate
> the pattern)
>
> But - when I try to do the equivalent in c# using the bindings :
>
> SpatialReference CRS = new SpatialReference();
> CRS.ImportFromMICoordSys(coordsys);
>
> I get a message
>
> error CS1729: 'SpatialReference' does not contain a constructor that takes
> 0 arguments
>
> Am I missing something? Or is this is a gap in the bindings?
> ___
> 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] OGR FileGDB driver: 'OBJECTID' not recognised as an available field

[Tamas Szekeres]

Hi,

I've already reported an issue a while back related to the OGRSQL dialect
along with the FDGB driver, when the where clause contains expression for
the FID column. I'm still experiencing the problem in GDAL master, where
the following query doesn't seem to apply the specified filter:

*ogrinfo "mydata.gdb" -dialect OGRSQL -sql "select * from tablename where
FID=..."*

but this one (without dialect) returns the correct result:

* ogrinfo "mydata.gdb" -sql "select * from tablename where FID=..."  *

I'm a bit uncertain about whether it should be fixed in the generic SQL
layer or the FGDB layer (which doesn't expose OBJECTID in the layer defn.),
since the FGDB layer reports the name "OBJECTID" in GetFIDColumn, therefore
the gen SQL layer could automatically consider it in the layer definition
when processing the attribute filter. When adding the OBJECTID to the query
it fixes the problem, but that seems to be a bit awkward:

*ogrinfo "mydata.gdb" -dialect OGRSQL -sql "select *, OBJECTID from
tablename where FID=..." *

Any ideas in this topic would be helpful?

Best regards,

Tamas


Tamas Szekeres  ezt írta (időpont: 2019. szept. 5.,
Cs, 22:51):

> Hi,
>
> I'm not sure if bForwardWhereToSourceLayer should not be set in this case,
> since the special field FID in pszWHEREIn has already been replaced.
> Or the OpenFileGDB driver should indeed expose OBJECTID as a column
> according to #4253
>
> Best regards,
>
> Tamas
>
>
>  Even Rouault  ezt írta (időpont: 2019.
> szept. 5., Cs, 13:13):
>
>> On mercredi 4 septembre 2019 22:13:40 CEST Tamas Szekeres wrote:
>> > Hi,
>> >
>> > It looks like  the sql queries with -dialect "OGRSQL" doesn't seem to
>> work
>> > as expected. When I specify the FID in the where clause, it doesn't
>> filter
>> > anything. The same query is also described as a solution in the
>> following
>> > ticket https://trac.osgeo.org/gdal/ticket/4253 but I doubt if that
>> works at
>> > all.
>> >
>> > The code causing this problem is fairly generic (ogr_gensql.cpp)
>> >
>> > if( psSelectInfo->where_expr && pszDialect != nullptr &&
>> > EQUAL(pszDialect, "OGRSQL") )
>> > {
>> > int nMinIndexForSpecialField =
>> > poSrcLayer->GetLayerDefn()->GetFieldCount();
>> > bForwardWhereToSourceLayer =
>> > !OGRGenSQLResultsLayerHasSpecialField
>> > (psSelectInfo->where_expr,
>> > nMinIndexForSpecialField);
>> > }
>> > if (bForwardWhereToSourceLayer)
>> > pszWHERE = CPLStrdup(pszWHEREIn);
>> > else
>> > pszWHERE = nullptr;
>> >
>> > In the "where" expression, the FID field is thanslated to OBJECTID and
>> it
>> > is now treated as a special field, therefore the "where" expression is
>> not
>> > being passed to the driver.
>> >
>> > I'm also unsure if that is a correct action to omit passing "where" to
>> the
>> > layer instead of providing an error message.
>>
>> Actually the where isn't completely discarded. It is set on the
>> OGRGenSQLResultsLayer per
>>
>> if( !bForwardWhereToSourceLayer )
>> OGRGenSQLResultsLayer::SetAttributeFilter( pszWHEREIn );
>>
>> around line 492
>>
>> The issue is that the GenSQL layer has no FID column set, and thus this
>> filter
>> fails. One could potentially set the FID Column name on it from the
>> source
>> layer, but that wouldn't be really appropriate in the case of JOIN. That
>> said
>> I see a poDstFeat->SetFID( poSrcFeat->GetFID() ); at line 1332 of
>> TranslateFeature(), so...
>>
>> (there might have been other fixes since #4253 that have made this case
>> broken)
>>
>> --
>> 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] GDAL and proj dll name.

[Tamas Szekeres]

Hi Even,

Thank you, I've not considered to modify the linking behavior of proj.dll
at this stage, but as far as it solves the problem I'm fine with it.

Best regards,

Tamas


Even Rouault  ezt írta (időpont: 2020. jan.
22., Sze, 15:01):

> Hi Tamas,
>
> > However the GDAL build (like for
> > https://github.com/OSGeo/gdal/blob/v2.4.4/gdal/ogr/ogrct.cpp) still
> using
> > the default proj.dll name which cannot be configured in the opt file.
>
> It can. You need to define -DPROJ_STATIC for that. -DPROJ_STATIC is a bit
> confusing. It didn't mean a static build, but something that was linked at
> build time (either a static or dynamic lib), to be opposed at being loaded
> at
> runtime with LoadLibrary(). That's what you want to use.
>
> # PROJ stuff
> # Uncomment the following lines to link PROJ library statically. Otherwise
> # it will be linked dynamically during runtime.
> # To use the new API of proj5 or later, use
> #PROJ_FLAGS = -DPROJ_STATIC -DPROJ_VERSION=5
> # for proj 4.x:
> #PROJ_FLAGS = -DPROJ_STATIC -DPROJ_VERSION=4
>
> #PROJ_INCLUDE = -Id:\projects\proj.4\src
> #PROJ_LIBRARY = d:\projects\proj.4\src\proj_i.lib
>
> 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] GDAL and proj dll name.

[Tamas Szekeres]

Hi,

As far as I see the current cmake builds of proj4/proj6 includes the proj
version number into the dll names like *proj_4_9.dll* for a Windows build.

However the GDAL build (like for
https://github.com/OSGeo/gdal/blob/v2.4.4/gdal/ogr/ogrct.cpp) still using
the default proj.dll name which cannot be configured in the opt file.

It is true that if we set the PROJSO config option properly the problem
disappears, something like:

Gdal.SetConfigOption("PROJSO", "proj_4_9.dll");

But that could also be avoided if there was a compile time setting to
specify the proj dll name. Does it make sense to establish a compile time
option for this purpose?

Thanks,

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

Re: [gdal-dev] Motion: request 2000 USD from OSGeo for GDAL

[Tamas Szekeres]

+1

Tamas

Even Rouault  ezt írta (időpont: 2020. jan.
10., P, 18:43):

> Hi,
>
> Motion: the GDAL project requests to OSGeo a 2000 USD budget for 2020
>
> ~
>
> +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] using gdal_viewshed

[Tamas Szekeres]

The fix has now been committed to GDAL/master

Tamas

Tamas Szekeres  ezt írta (időpont: 2019. nov. 12., K,
22:37):

> I've recently fixed the implementation in my local version causing a
> similar issue (RasterIO error when writing target raster), where the given
> maxdistance setting would produce an empty row at the top or the bottom of
> the result image.
> I'll prepare a fix in gdal in the next few days and let us see if that
> fixes this issue as well.
>
> Best regards,
>
> Tamas
>
>
> Eli Adam  ezt írta (időpont: 2019. nov. 12., K,
> 22:26):
>
>> Hi Ben,
>>
>> On Sun, Nov 10, 2019 at 3:57 AM Ben Avrahami 
>> wrote:
>> >
>> > Hello all, I've been trying trying to use the newest gdal_viewshed in
>> gdal-dev release, and I've run into an error I can't quite understand.
>> >
>> > The input I've been using is:
>> >
>> > gdal_viewshed -md 1000 -ox "691868.511" -oy "3492031.487" > tiff> 
>>
>> It might be helpful to copy and paste your command so if there are
>> typos or otherwise, they can be spotted.
>>
>> A gdalinfo report on your input file could also be helpful.  That
>> would show coordinates of the image and allow looking at things like
>> are those coordinates within the image?  Is it in the coordinate
>> system of the image?  A gdalinfo report details that nicely.
>>
>> >
>> > And I get the response:
>> >
>> > ERROR 5: C:\temp\files\out.tif, band 1: Access window out of range
>> in RasterIO().  Requested
>> > (0,-1) of size 67x1 on raster of 67x67.
>> > ERROR 1: RasterIO error when writing target raster
>>
>> This makes it seem like something isn't lining up correctly.  With the
>> absence of information some random guess include: that the coordinate
>> is not within the image, or perhaps the coordinate is less than -md
>> 1000 units from the edge (although testing that on other data here
>> worked fine), that there are pixel alignment/resolution issues and
>> using coordinates not to three decimal places would work better.
>>
>> I see that gdal_viewshed -md 900 -ox 985710 -oy 658590
>> http://download.osgeo.org/gdal/data/aaigrid/095b_dem_90m.asc
>> output2.tif works
>>
>> and
>>
>> gdal_viewshed -md 800 -ox 985710 -oy 658590
>> http://download.osgeo.org/gdal/data/aaigrid/095b_dem_90m.asc
>> output3.tif fails with the error:
>>
>> 0ERROR 5: output3.tif, band 1: Access window out of range in
>> RasterIO().  Requested
>> (0,-1) of size 19x1 on raster of 19x19.
>> ERROR 1: RasterIO error when writing target raster
>>
>> it seems that -md must be a multiple of the resolution.
>>
>> Best regards, Eli
>>
>> >
>> > I get a similar error if I try to use the GDALViewshedGenerate C-API
>> function. The input us a valid WGS84-UTM tiff file, and the output is a
>> valid path, but the file does not actually exist until I run the command.
>> After I run the command, the output file is created but only filled
>> halfway. Any help at wall would be appreciated.
>> >
>> > regards, Ben
>> > ___
>> > 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
>
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] using gdal_viewshed

[Tamas Szekeres]

I've recently fixed the implementation in my local version causing a
similar issue (RasterIO error when writing target raster), where the given
maxdistance setting would produce an empty row at the top or the bottom of
the result image.
I'll prepare a fix in gdal in the next few days and let us see if that
fixes this issue as well.

Best regards,

Tamas


Eli Adam  ezt írta (időpont: 2019. nov. 12., K,
22:26):

> Hi Ben,
>
> On Sun, Nov 10, 2019 at 3:57 AM Ben Avrahami 
> wrote:
> >
> > Hello all, I've been trying trying to use the newest gdal_viewshed in
> gdal-dev release, and I've run into an error I can't quite understand.
> >
> > The input I've been using is:
> >
> > gdal_viewshed -md 1000 -ox "691868.511" -oy "3492031.487"  tiff> 
>
> It might be helpful to copy and paste your command so if there are
> typos or otherwise, they can be spotted.
>
> A gdalinfo report on your input file could also be helpful.  That
> would show coordinates of the image and allow looking at things like
> are those coordinates within the image?  Is it in the coordinate
> system of the image?  A gdalinfo report details that nicely.
>
> >
> > And I get the response:
> >
> > ERROR 5: C:\temp\files\out.tif, band 1: Access window out of range
> in RasterIO().  Requested
> > (0,-1) of size 67x1 on raster of 67x67.
> > ERROR 1: RasterIO error when writing target raster
>
> This makes it seem like something isn't lining up correctly.  With the
> absence of information some random guess include: that the coordinate
> is not within the image, or perhaps the coordinate is less than -md
> 1000 units from the edge (although testing that on other data here
> worked fine), that there are pixel alignment/resolution issues and
> using coordinates not to three decimal places would work better.
>
> I see that gdal_viewshed -md 900 -ox 985710 -oy 658590
> http://download.osgeo.org/gdal/data/aaigrid/095b_dem_90m.asc
> output2.tif works
>
> and
>
> gdal_viewshed -md 800 -ox 985710 -oy 658590
> http://download.osgeo.org/gdal/data/aaigrid/095b_dem_90m.asc
> output3.tif fails with the error:
>
> 0ERROR 5: output3.tif, band 1: Access window out of range in
> RasterIO().  Requested
> (0,-1) of size 19x1 on raster of 19x19.
> ERROR 1: RasterIO error when writing target raster
>
> it seems that -md must be a multiple of the resolution.
>
> Best regards, Eli
>
> >
> > I get a similar error if I try to use the GDALViewshedGenerate C-API
> function. The input us a valid WGS84-UTM tiff file, and the output is a
> valid path, but the file does not actually exist until I run the command.
> After I run the command, the output file is created but only filled
> halfway. Any help at wall would be appreciated.
> >
> > regards, Ben
> > ___
> > 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
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL 3.0 Nuget packages...

[Tamas Szekeres]

Hi Morten,

There have been problems with the GDAL 3.0 nuget versions, that's why that
was unlisted.
Specifically, the way how proj6 would want to find proj.db is not
satisfactory regarding to the C# applications.
I'm still working on a solution.

Best regards,

Tamas




Morten Breiner  ezt írta (időpont: 2019. okt. 3., Cs,
10:26):

> Hi,
>
> Currently, I am using GDAL 2.4.2 for some c# development in Visual Studio.
>
> I have installed the nuget packages found under
> https://www.nuget.org/packages/GDAL/2.4.2 (many thanks to all involved
> in maintaining those).
>
>  From the download statistics
> (https://www.nuget.org/stats/packages/GDAL?groupby=Version), I can see
> that some attempt to support GDAL 3.0 has been made, but the packages
> have been unlisted unfortunately.
>
> Does any of you know if a release of nuget packages for GDAL 3.0 has
> been scheduled or as an alternative, if recommended GDAL 3.0 packages
> for c# can be downloaded elsewhere?
>
> Many thanks in advance for clarifying answers.
>
> BR
> -Morten Breiner
> ___
> 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] Generating Viewsheds without Using Sightlines

[Tamas Szekeres]

As far as I see, the size of the output raster is equal to the input size
with the gdaldem utility set.
With the viewshed approach, the size of the output raster is calculated
according to the provided parameters (ie. the observer location and
maxdistance), however it is a good idea to allow the user customize the
output format is some way.

Best regards,

Tamas


Eli Adam  ezt írta (időpont: 2019. szept. 30., H,
21:35):

> On Mon, Sep 30, 2019 at 11:54 AM Even Rouault
>  wrote:
> >
> > On lundi 30 septembre 2019 20:10:38 CEST Tamas Szekeres wrote:
> > > Hi,
> > >
> > > I've implemented a viewshed algorithm a while ago, by utilizing a
> modified
> > > version of the algorithm published at
> > >
> https://www.asprs.org/wp-content/uploads/pers/2000journal/january/2000_jan_8
> > > 7-90.pdf
> > >
> > > With this approach, it was crucial to provide a fast real-time option
> for
> > > the viewshed calculation on relatively large raster DEMs by using only
> a
> > > small memory footprint.
> > >
> > > The implementation can be found here:
> > >
> > > https://github.com/szekerest/gdal/blob/viewshed/gdal/alg/viewshed.cpp
> > >
> https://github.com/szekerest/gdal/blob/viewshed/gdal/apps/gdal_viewshed.cpp
> > >
> > > Does it make sense to spend some more effort and incorporate this
> approach
> > > in GDAL officially?
> >
> > Sounds useful to me !
> > (old memories of having implement line-of-sight based intervisibility
> > algorithm in a past life !)
>
> Gdaldem (although it has a different history) has an assortment of DEM
> based utilities, https://gdal.org/programs/gdaldem.html  I'm not sure
> if it would make sense there or elsewhere.  It would be a useful tool.
>
> Best regards, Eli
>
>
>
> >
> > 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
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Generating Viewsheds without Using Sightlines

[Tamas Szekeres]

Hi,

I've implemented a viewshed algorithm a while ago, by utilizing a modified
version of the algorithm published at
https://www.asprs.org/wp-content/uploads/pers/2000journal/january/2000_jan_87-90.pdf

With this approach, it was crucial to provide a fast real-time option for
the viewshed calculation on relatively large raster DEMs by using only a
small memory footprint.

The implementation can be found here:

https://github.com/szekerest/gdal/blob/viewshed/gdal/alg/viewshed.cpp
https://github.com/szekerest/gdal/blob/viewshed/gdal/apps/gdal_viewshed.cpp

Does it make sense to spend some more effort and incorporate this approach
in GDAL officially?

Best regards,

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

Re: [gdal-dev] Nomination of Sean Gillies for the GDAL PSC

[Tamas Szekeres]

+1

Tamas

Howard Butler  ezt írta (időpont: 2019. szept. 17., K,
15:22):

> All,
>
> I would like to nominate Sean Gillies to the GDAL PSC.
>
> Sean leads the development of two important Python geospatial projects
> based on GDAL/OGR – rasterio and Fiona. He has contributed many bug reports
> and design ideas to GDAL while developing those libraries, and he brings
> nearly twenty years of active open source geospatial software contribution
> experience with him. His API sensibilities will continue provide invaluable
> direction and perspective going forward as GDAL continues to (slowly)
> evolve.
>
> I'll start with a +1.
>
> Howard
> ___
> 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] Nomination of Mateusz Łoskot for the GDAL PSC

[Tamas Szekeres]

+1

Tamas

Howard Butler  ezt írta (időpont: 2019. szept. 17., K,
15:22):

> All,
>
> I would like to nominate Mateusz Łoskot to the GDAL PSC.
>
> Mateusz has been an active contributor to the GDAL project for nearly
> fifteen years. He was the very first paid maintainer for the project,
> closing bugs and running down issues, and his C/C++ expertise has helped
> the project evolve as it has moved to C++11. He is also very helpful with
> mailing list questions, and his experience and history with the project
> make him an excellent candidate for participating in the GDAL PSC.
>
> I'll start with a +1.
>
> Howard
> ___
> 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] OGR FileGDB driver: 'OBJECTID' not recognised as an available field

[Tamas Szekeres]

Hi,

I'm not sure if bForwardWhereToSourceLayer should not be set in this case,
since the special field FID in pszWHEREIn has already been replaced.
Or the OpenFileGDB driver should indeed expose OBJECTID as a column
according to #4253

Best regards,

Tamas


 Even Rouault  ezt írta (időpont: 2019. szept.
5., Cs, 13:13):

> On mercredi 4 septembre 2019 22:13:40 CEST Tamas Szekeres wrote:
> > Hi,
> >
> > It looks like  the sql queries with -dialect "OGRSQL" doesn't seem to
> work
> > as expected. When I specify the FID in the where clause, it doesn't
> filter
> > anything. The same query is also described as a solution in the following
> > ticket https://trac.osgeo.org/gdal/ticket/4253 but I doubt if that
> works at
> > all.
> >
> > The code causing this problem is fairly generic (ogr_gensql.cpp)
> >
> > if( psSelectInfo->where_expr && pszDialect != nullptr &&
> > EQUAL(pszDialect, "OGRSQL") )
> > {
> > int nMinIndexForSpecialField =
> > poSrcLayer->GetLayerDefn()->GetFieldCount();
> > bForwardWhereToSourceLayer =
> > !OGRGenSQLResultsLayerHasSpecialField
> > (psSelectInfo->where_expr,
> > nMinIndexForSpecialField);
> > }
> > if (bForwardWhereToSourceLayer)
> > pszWHERE = CPLStrdup(pszWHEREIn);
> > else
> > pszWHERE = nullptr;
> >
> > In the "where" expression, the FID field is thanslated to OBJECTID and it
> > is now treated as a special field, therefore the "where" expression is
> not
> > being passed to the driver.
> >
> > I'm also unsure if that is a correct action to omit passing "where" to
> the
> > layer instead of providing an error message.
>
> Actually the where isn't completely discarded. It is set on the
> OGRGenSQLResultsLayer per
>
> if( !bForwardWhereToSourceLayer )
> OGRGenSQLResultsLayer::SetAttributeFilter( pszWHEREIn );
>
> around line 492
>
> The issue is that the GenSQL layer has no FID column set, and thus this
> filter
> fails. One could potentially set the FID Column name on it from the source
> layer, but that wouldn't be really appropriate in the case of JOIN. That
> said
> I see a poDstFeat->SetFID( poSrcFeat->GetFID() ); at line 1332 of
> TranslateFeature(), so...
>
> (there might have been other fixes since #4253 that have made this case
> broken)
>
> --
> 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] OGR FileGDB driver: 'OBJECTID' not recognised as an available field

[Tamas Szekeres]

Hi,

It looks like  the sql queries with -dialect "OGRSQL" doesn't seem to work
as expected. When I specify the FID in the where clause, it doesn't filter
anything. The same query is also described as a solution in the following
ticket https://trac.osgeo.org/gdal/ticket/4253 but I doubt if that works at
all.

The code causing this problem is fairly generic (ogr_gensql.cpp)

if( psSelectInfo->where_expr && pszDialect != nullptr &&
EQUAL(pszDialect, "OGRSQL") )
{
int nMinIndexForSpecialField =
poSrcLayer->GetLayerDefn()->GetFieldCount();
bForwardWhereToSourceLayer =
!OGRGenSQLResultsLayerHasSpecialField
(psSelectInfo->where_expr,
nMinIndexForSpecialField);
}
if (bForwardWhereToSourceLayer)
pszWHERE = CPLStrdup(pszWHEREIn);
else
pszWHERE = nullptr;

In the "where" expression, the FID field is thanslated to OBJECTID and it
is now treated as a special field, therefore the "where" expression is not
being passed to the driver.

I'm also unsure if that is a correct action to omit passing "where" to the
layer instead of providing an error message.

Is this a bug that should be fixed, or the OGRSQL dialect is considered as
unsupported with OpenFileGDB?


Best regards,

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

Re: [gdal-dev] Motions: promote GDAL 2.4.2 RC1 and GDAL 3.0.1 RC1 to final

[Tamas Szekeres]

+1 for both.

Best regards,

Tamas


Even Rouault  ezt írta (időpont: 2019. júl. 3.,
Sze, 11:16):

> Hi,
>
> Motion 1: promote GDAL 2.4.2 RC1 to final
> Motion 2: promote GDAL 3.0.1 RC1 to final
>
> ~
>
> My votes:
> Motion 1: +1
> Motion 2: +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] Getting all known coordinate systems.

[Tamas Szekeres]

Do we have a ticket for this addition? I can take care of the c# part.

Best regards,

Tamas

Sent from my iPhone

2019. jún. 20. dátummal, 14:59 időpontban Even Rouault 
 írta:

>> On jeudi 20 juin 2019 05:46:45 CEST Franik wrote:
>> I am updating to GDAL 3.0 (C# bindings).
>> 
>> I need a list of all the supported coordinate systems in my application.
>> 
>> In the older versions, I requested all the known coordinate systems by
>> reading the csv files in the GDAL_DATA folder (pcs.csv, gcs.csv,...).
>> 
>> In the the new version, the csv files have been replaced by the proj.db
>> file. Does anyone know of a good way to get all the coordinate systems.
>> Should I just try to read the proj.db file myself and extract all the
>> records? Or is there some kind of method exposed for this?
> 
> There's a osr.GetCRSInfoListFromDatabase() method in the SWIG bindings 
> (binding of OSRGetCRSInfoListFromDatabase()), but it is only exposed for the 
> Python bindings currently. 
> 
> A new SWIG typemap should be written for the other binding languages, so that 
> osr.GetCRSInfoListFromDatabase() can be used with them.
> 
> 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] Motion: Add Norman Barker to GDAL PSC

[Tamas Szekeres]

+1

Tamas

Even Rouault  ezt írta (időpont: 2019. máj.
15., Sze, 16:04):

> Hi,
>
> I propose to add Norman Barker to the GDAL project steering committee.
>
> Norman has been active as a contributor to the GDAL project since more
> than 10
> years and has contributed to various areas of the project, in particular
> the
> JPIPKAK driver and the progressive rendering API, the OGR Cloudand driver,
> the
> WEBP codec for GeoTIFF, and recently the TileDB driver. I believe he would
> be
> a good asset for the project.
>
> Motion: To add Norman Barker to the GDAL PSC.
>
> +1 from me.
>
> 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] Motion: Promote GDAL 2.4.1 rc1 for release

[Tamas Szekeres]

+1

Tamas

Even Rouault  ezt írta (időpont: 2019. márc.
20., Sze, 11:41):

> Hi,
>
> No issues were raised about this release candidate, so
>
> ---
>
> Motion: GDAL/OGR 2.4.1 rc1 is promoted to be the official 2.4.1 final
> release.
>
> ---
>
> My vote: +1
>
> Best regards,
>
> 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] Motion: Promote GDAL 2.4.0 rc1 for release

[Tamas Szekeres]

+1

Tamas


Even Rouault  ezt írta (időpont: 2018. dec.
19., Sze, 14:11):

> Hi,
>
> Motion: GDAL/OGR 2.4.0 rc1 is promoted to be the official 2.4.0  final
> release.
>
> ---
>
> My vote: +1
>
> ---
>
> I didn't have any feedback on this one, so I assume things go well.
>
> 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] Motion: Promote GDAL 2.3.3 rc2 for release

[Tamas Szekeres]

+1

Tamas


Even Rouault  ezt írta (időpont: 2018. dec.
18., K, 12:35):

> Hi,
>
> Motion: GDAL/OGR 2.3.3 rc2 is promoted to be the official 2.3.3 final
> release.
>
> ---
>
> My vote: +1
>
> ---
>
> Note: https://github.com/OSGeo/gdal/issues/1156 was raised yesterday.
> Would
> have been good if it had been in 2.3.3 but I don't really feel like doing
> another RC for that, so that will be for 2.4.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] How to use Gdal c# bindings with .NET Core

[Tamas Szekeres]

"Official" binaries are not being provided by GDAL directly. However, in
the near future, I'm planning to support ".net standard 2.1" with the nuget
packages derived from the binaries of https://www.gisinternals.com.

Best regards,

Tamas


Gigas002  ezt írta (időpont: 2018. dec. 15., Szo,
21:05):

> Thanks! That worked for me. But of course anyone would prefer official
> release, so... Is .net core bindings planned?
>
>
>
> --
> Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
> ___
> 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] How to use Gdal c# bindings with .NET Core

[Tamas Szekeres]

At the moment it looks like only the 3rd option below supports .net core.
However since that is a custom build, use the dependencies
(gdal_wrap.dll etc.) provided by the same bundle, ie:
https://www.nuget.org/packages/Gdal.Core.WindowsRuntime/2.3.0-beta-023
These dll-s support x64 only as far as I see.

Best regards,

Tamas



Gigas002  ezt írta (időpont: 2018. dec. 15., Szo,
15:50):

> Hello everyone. I'm trying to use c# bindings with .NET Core 2.0 on Visual
> Studio 2017.
> Tried to use multiple nuget packages:
> 1. https://www.nuget.org/packages/GDAL/ +
> https://www.nuget.org/packages/GDAL.Native/
> I used these packages for my .NET Framework project and it worked fine, but
> it doesn't compile on .NET Core. The namespace OSGeo just couldn't been
> seen
> and " 'GDAL.Native 2.3.2' package was restored using
> '.NETFramework,Version=v4.6.1' " warning is thrown by VS.
> 2. https://www.nuget.org/packages/GDAL.NET/
> Throws the same warning about .NET Framework 4.6.1 and requires to write
> GdalConfiguration class, because Gdal.AllRegister() method wouldn't work.
> 3. https://www.nuget.org/packages/Gdal.Core/2.3.0-beta-023 +
> https://www.nuget.org/packages/Gdal.Core.WindowsRuntime/2.3.0-beta-023 +
> https://www.nuget.org/packages/Gdal.Core.LinuxRuntime/2.3.0-beta-023
> Doesn't throw any warnings/errors, compiles fine and Gdal.AllRegister()
> method works OK.
>
> So, the built application works with the 3rd set of packages. But after
> building the app, I use VS's "publish" to create standalone win-x64 and
> linux-x64 app. And this version doesn't work at all.
> At first it throws exception, because it couldn't find gdal_wrap.dll, if
> I'll copy all needed dll's and the content from gdal-data directory from
> pre-built gdal binaries (taken from here for example:
>
> http://www.gisinternals.com/query.html?content=filelist=release-1911-x64-gdal-mapserver.zip
> )
> to the directory with published .exe file, it'll throw another error:
> System.EntryPointNotFoundException: Unable to find an entry point named
> 'CSharp_OSGeofGDAL_AllRegister___' in DLL 'gdal_wrap'.
> So, probably I'm doing something wrong? Is there a complete guide how to
> use
> gdal bindings with .NET Core to built standalone application? Thanls in
> advance for your reply!
>
>
>
> --
> Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
> ___
> 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] Dataset's ReadRaster/WriteRaster throws exception on c#

[Tamas Szekeres]

You did not count the band size when allocating memory for the buffer.
That should be:

byte[] readRaster = new byte[tileSize * tileSize * 4];

Or alternatively use Band.ReadRaster to read just a specific band.

Best regards,

Tamas




Gigas002  ezt írta (időpont: 2018. nov. 12., H, 17:34):

> Hi all.
> I've rewritten some python code from gdal2tiles.py on c#, using GDAL.NET
> nuget package (ver. 2.3.1). Here you can see the working python code:
>
> def create_overview_tiles(input_file, output_file):
> tile_driver = 'PNG'
> tile_size = 256
> tilebands = 4
> resampling = 'bilinear'
>
> mem_driver = gdal.GetDriverByName('MEM')
> out_driver = gdal.GetDriverByName(tile_driver)
>
> dsquery = mem_driver.Create('', 2 * tile_size, 2 * tile_size,
> tilebands)
> dstile = mem_driver.Create('', tile_size, tile_size, tilebands)
> dsquerytile = gdal.Open(input_file, gdal.GA_ReadOnly)
>
> dsquery.WriteRaster(0, 0, tile_size, tile_size,
> dsquerytile.ReadRaster(0,
> 0, tile_size, tile_size), band_list=list(range(1, tilebands + 1)))
> scale_query_to_tile(dsquery, dstile, resampling)
> out_driver.CreateCopy(output_file, dstile, strict=0)
>
>
> def scale_query_to_tile(dsquery, dstile, resampling):
> querysize = dsquery.RasterXSize
> tilesize = dstile.RasterXSize
>
> if resampling == 'near':
> gdal_resampling = gdal.GRA_NearestNeighbour
>
> elif resampling == 'bilinear':
> gdal_resampling = gdal.GRA_Bilinear
>
> elif resampling == 'cubic':
> gdal_resampling = gdal.GRA_Cubic
>
> elif resampling == 'cubicspline':
> gdal_resampling = gdal.GRA_CubicSpline
>
> dsquery.SetGeoTransform((0.0, tilesize / float(querysize), 0.0, 0.0,
> 0.0, tilesize / float(querysize)))
> dstile.SetGeoTransform((0.0, 1.0, 0.0, 0.0, 0.0, 1.0))
>
> gdal.ReprojectImage(dsquery, dstile, None, None, gdal_resampling)
>
>
> And here's rewritten code on c#:
>
> private static void BuildOverview(string inputFile, string
> outputFile)
> {
> const string tileDriver = "PNG";
> const int tileSize = 256;
> const int tileBands = 4;
> const string resampling = "bilinear";
>
> Driver memDriver = Gdal.GetDriverByName("MEM");
> Driver outDriver = Gdal.GetDriverByName(tileDriver);
>
> Dataset dsQuery = memDriver.Create("", 2 * tileSize, 2 *
> tileSize, tileBands, DataType.GDT_Byte, null);
> Dataset dsTile = memDriver.Create("", tileSize, tileSize,
> tileBands, DataType.GDT_Byte, null);
> Dataset dsQueryTile = Gdal.Open(inputFile, Access.GA_ReadOnly);
>
> byte[] readRaster = new byte[tileSize * tileSize];
> dsQueryTile.ReadRaster(0, 0, tileSize, tileSize, readRaster,
> tileSize, tileSize,
> tileBands, Enumerable.Range(1, tileBands + 1).ToArray(), 0,
> 0, 0);
> dsQuery.WriteRaster(0, 0, tileSize, tileSize, readRaster,
> tileSize, tileSize,
> tileBands, Enumerable.Range(1, tileBands + 1).ToArray(), 0,
> 0, 0);
>
> ScaleQueryToTile(dsQuery, dsTile, resampling);
> outDriver.CreateCopy(outputFile, dsTile, 0, null, null, null);
> }
>
> private static void ScaleQueryToTile(Dataset dsQuery, Dataset
> dsTile, string resampling)
> {
> int querySize = dsQuery.RasterXSize;
> int tileSize = dsTile.RasterXSize;
>
> ResampleAlg gdalResampling;
> switch (resampling)
> {
> case "near":
> gdalResampling = ResampleAlg.GRA_NearestNeighbour;
> break;
> case "bilinear":
> gdalResampling = ResampleAlg.GRA_Bilinear;
> break;
> case "cubicspline":
> gdalResampling = ResampleAlg.GRA_CubicSpline;
> break;
> default:
> gdalResampling = ResampleAlg.GRA_Cubic;
> break;
> }
>
> dsQuery.SetGeoTransform(new[] {0.0, tileSize / (float)
> querySize, 0, 0, 0, tileSize / (float) querySize});
> dsTile.SetGeoTransform(new[] { 0.0, 1.0, 0.0, 0.0, 0.0, 1.0 });
>
> Gdal.ReprojectImage(dsQuery, dsTile, null, null,
> gdalResampling,
> 0, 0, null, null, null);
> }
>
>
> I use these methods to create upper tile (in my case create 10 lvl tile
> from
> 11 lvl tile). Python version works without problem, but c#'s throws
> "System.AccessViolationException" (Additional information on exception from
> VS: Attempted to read or write protected memory. This is often an
> indication
> that other memory is corrupt) on "dsQueryTile.ReadRaster(..." line in
> runtime.
> I suppose the exception is thrown because ReadRaster try to create pointer
> to byte[] and somehow fails.
>
> I uploaded the 

Re: [gdal-dev] How to Use Gdal in Microsoft Visual Studio C++

[Tamas Szekeres]

Packages for GDAL have also been submitted to nuget.org  (GDAL, GDAL.Native
and GDAL.Plugins) which could be referenced in your Visual Studio project
easily.


Best regards,

Tamas

Ivan Lucena  ezt írta (időpont: 2018. nov. 7.,
Sze, 14:44):

> Hi Athin,
>
> Here it goes again:
>
> https://github.com/OSGeo/gdal/tree/master/gdal/swig/csharp/apps
>
> For more information on GDAL's C# API:
>
> https://trac.osgeo.org/gdal/wiki/GdalOgrInCsharp
>
> Regards,
>
> Ivan
>
> On 11/6/18, 8:34 PM, "gdal-dev on behalf of Athin" <
> gdal-dev-boun...@lists.osgeo.org on behalf of mohdfathin3...@gmail.com>
> wrote:
>
> Hai Ivan,
>
> May i know the function of the swig(c#) that you share to me?
>
> Thank you and best regards
>
>
>
> --
> Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
> ___
> 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
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL.NET System.TypeInitializationException

[Tamas Szekeres]

Not sure how you project is looking like, I thought you added the GDAL.NET
nuget package as the reference.
Within this package, you can find some code GdalConfiguration.cs, where the
static constructor contains the necessary code to set up the environment
programmatically.
Alternatively you can set the corresponding environment variables manually
on your system so as to get the things working.

Best regards,

Tamas



Scott Senften  ezt írta (időpont: 2018. okt. 27., Szo,
20:14):

>
> Thank you for quick response.
>
> No, I don't see the configuration calls being used. I'm working from the
> examples in the gdal/swig/csharp/apps directory, specifically
> https://github.com/OSGeo/gdal/blob/master/gdal/swig/csharp/apps/OGRGEOS.cs
>
> I haven't written any code for myself yet. I'm just trying to confirm I
> have a proper dev environment setup using the given demos. Is there a
> better starting point for c#/dotnet development?  Is there a quick start or
> a tutorial that I missed?
>
> Thanks again.
>
> Scott
>
> On Sat, Oct 27, 2018 at 9:12 AM Tamas Szekeres 
> wrote:
>
>> Scott,
>>
>> Have you called  GdalConfiguration.ConfigureGdal() and/or
>> GdalConfiguration.ConfigureOgr() at the beginning of your code?
>>
>> Best regards,
>>
>> Tamas
>>
>>
>>
>>
>> Scott Senften  ezt írta (időpont: 2018. okt. 26., P,
>> 23:59):
>>
>>>
>>> My apologies; I'm guessing this is well trod ground, but I couldn't find
>>> a good search for the archives and, on inspection, I couldn't find an
>>> appropriate topic.
>>>
>>> I'm trying to build one of the GDAL swig c# examples, specifically I
>>> have tried both OGRGEOS and ORSTransform. I've installed GDAL.NET 2.3.1
>>> from nuget (https://www.nuget.org/packages/GDAL.NET/). My projects
>>> build but both throw System.TypeInitializationException at runtime.
>>>
>>> For OGRGEOS, the error is
>>>
>>>> Exception thrown: 'System.TypeInitializationException' in ogr_csharp.dll
>>>> An unhandled exception of type 'System.TypeInitializationException'
>>>> occurred in ogr_csharp.dll
>>>> The type initializer for 'OSGeo.OGR.OgrPINVOKE' threw an exception.
>>>>
>>>> The program '[34872] dotnet.exe' has exited with code -1073741510
>>>> (0xc13a).
>>>>
>>>
>>> I'm guessing that I either have a configuration issue or a dependency
>>> issue with the underlying native code, but, at this point, I'm just
>>> guessing.
>>>
>>> Any help would be appreciated,
>>>
>>> Scott
>>>
>>> ___
>>> 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
>
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL.NET System.TypeInitializationException

[Tamas Szekeres]

Scott,

Have you called  GdalConfiguration.ConfigureGdal() and/or
GdalConfiguration.ConfigureOgr() at the beginning of your code?

Best regards,

Tamas




Scott Senften  ezt írta (időpont: 2018. okt. 26., P,
23:59):

>
> My apologies; I'm guessing this is well trod ground, but I couldn't find a
> good search for the archives and, on inspection, I couldn't find an
> appropriate topic.
>
> I'm trying to build one of the GDAL swig c# examples, specifically I have
> tried both OGRGEOS and ORSTransform. I've installed GDAL.NET 2.3.1 from
> nuget (https://www.nuget.org/packages/GDAL.NET/). My projects build but
> both throw System.TypeInitializationException at runtime.
>
> For OGRGEOS, the error is
>
>> Exception thrown: 'System.TypeInitializationException' in ogr_csharp.dll
>> An unhandled exception of type 'System.TypeInitializationException'
>> occurred in ogr_csharp.dll
>> The type initializer for 'OSGeo.OGR.OgrPINVOKE' threw an exception.
>>
>> The program '[34872] dotnet.exe' has exited with code -1073741510
>> (0xc13a).
>>
>
> I'm guessing that I either have a configuration issue or a dependency
> issue with the underlying native code, but, at this point, I'm just
> guessing.
>
> Any help would be appreciated,
>
> Scott
>
> ___
> 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] Motion: Promote GDAL 2.3.1 rc2 for release

[Tamas Szekeres]

+1

Tamas


2018-06-25 15:18 GMT+02:00 Even Rouault :

> Hi,
>
> Motion: GDAL/OGR 2.3.1 rc2 is promoted to be the official 2.3.1 final
> release.
>
> ---
>
> My vote: +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] mssql import speed

[Tamas Szekeres]

Hi Martin,

Thanks for the data.
Fixed this one in this PR:

https://github.com/OSGeo/gdal/pull/621

Best regards,

Tamas

2018-05-12 21:59 GMT+02:00 Martin Landa <landa.mar...@gmail.com>:

> Hi,
>
> 2018-05-12 16:17 GMT+02:00 Tamas Szekeres <szeker...@gmail.com>:
> > Can I get the sample data for this?
>
> sure [1].
>
> > Looks like more than one table is set "IDENTITY_INSERT ON" at the same
> time.
>
> Steps to reproduce (tested with SQL Server 2014):
>
> 1) create new mssql db
> 2) C:\OSGeo4W64/apps/gdal-dev/bin/ogr2ogr -f MSSQLSpatial --config
> GDAL_DRIVER_PATH C:\OSGeo4W64\apps\gdal-dev\bin\gdalplugins --config
> MSSQLSPATIAL_LIST_ALL_TABLES YES %connstr% %filedb%
>
> Thanks! Martin
>
> [1] http://geo102.fsv.cvut.cz/~landa/tmp/Export_vse.db.7z
>
> --
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.cz/mentors/landa
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] mssql import speed

[Tamas Szekeres]

Hi Martin,

Can I get the sample data for this?
Looks like more than one table is set "IDENTITY_INSERT ON" at the same time.

Best regards,

Tamas


2018-05-12 16:10 GMT+02:00 Martin Landa :

> Hi,
>
> 2018-05-12 15:51 GMT+02:00 Martin Landa :
>
> > ERROR 1: Failed to set identity insert on layer, [Microsoft][SQL Server
> Native C
> > lient 11.0][SQL Server]IDENTITY_INSERT is already ON for table
> 'kn2.dbo.par'. Ca
> > nnot perform SET operation for table 'dbo.bud'..
> > ERROR 1: Unable to write feature 1 from layer BUD.
> > ERROR 1: Terminating translation prematurely after failed
> > translation of layer BUD (use -skipfailures to skip errors)
>
> Input DB has about 50 layers, see
>
> ...
> 1: PAR (None)
> 2: BUD (None)
> 3: ZPOCHN (None)
> ...
>
> It seems that all records from PAR layer are sucessfully writen to
> target PAR table in MSSQL. Writing features from second layer (BUD)
> fails. No records written. It must be related to BCP. Martin
>
> --
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.cz/mentors/landa
> ___
> 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] Motion: Promote GDAL 2.3.0 RC1 for release

[Tamas Szekeres]

+1

Tamas

2018-05-09 8:58 GMT+02:00 Even Rouault :

> Hi,
>
>
>
> No critical issues have been raised on RC1, so
>
>
>
> ---
>
>
>
> Motion: GDAL/OGR 2.3.0 RC1 is promoted to be the official 2.3.0 final
> release.
>
>
>
> ---
>
>
>
> My vote: +1
>
>
>
> --
>
> 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] mssql import speed

[Tamas Szekeres]

Hi Martin,

Try to check in the SQL profiler that the BCP was successfully enabled and
not plain insert statements are executed. (ie. the BCP enabled plugin was
loaded)
If BCP was enabled you might also try to load data on the server machine,
so the network doesn't limit the bandwidth.

Otherwise we don't seem to have more options.

Best regards,

Tamas


2018-05-10 19:18 GMT+02:00 Martin Landa :

> Hi,
>
> I wonder how to speed up import to MSSQL. I have testing SQLite DB
> (~1GB) with 48 tables (overall number of records 11e6). I started with
>
> $ ogr2ogr -f MSSQLSpatial MSSQL:... test.db
>
> It took more than 3hours! Tested on Windows computer with SQL Server
> 2012. I used SQL Server Native Client 11.0.
>
> So I tried to enable BCP (which should be enable anyway) and increased its
> size:
>
> $ ogr2ogr -f MSSQLSpatial MSSQL:... --config MSSQLSPATIAL_USE_BCP YES
> --config MSSQLSPATIAL_BCP_SIZE 1 test.db
>
> No difference, more than 3 hours. Anything I could miss?  It's my
> first experience with MSSQL. Anything related to configuration or so?
> Thanks for pointers in advance! Martin
>
> --
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.cz/mentors/landa
> ___
> 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] connect mssql from linux

[Tamas Szekeres]

What if you disable bulk insert with "-config MSSQLSPATIAL_USE_BCP NO" ?

Best regards,

Tamas


2018-05-08 18:44 GMT+02:00 Martin Landa :

> Hi,
>
> 2018-05-07 1:37 GMT+02:00 Jeremy Palmer :
> > Note I alway found the FreeTDS driver would truncate values on rows that
> > contained large geometries. Can't remember the size limit though. Would
> be
> > interesting to know why the LINUX native driver doesn't work.
>
> my experience is even worse. It truncate in my case all strings (even
> short strings with two characters). Just first character is written do
> DB! Martin
>
> --
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.cz/mentors/landa
> ___
> 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] mssql append fails for non-geometry layers

[Tamas Szekeres]

Hi Martin,

For some reason the table hasn't been found and the driver wanted to create
a new table.
I've tried to reproduce this with a shapefile with no geometry uploaded to
MSSQL, but I couldn't.
Can I have your sample data? Which GDAL version has been used?
You could also check what happens by disabling bulk insert by adding *--config
MSSQLSPATIAL_USE_BCP NO*


Thanks,

Tamas


2018-05-03 19:31 GMT+02:00 Martin Landa :

> Hi all,
>
> let's assume sample data:
>
> $ ogrinfo sample.gpkg
>
> 1: SOBR (Point)
> 2: VLA (None)
>
> Append for geometry layers seems to work:
>
> 1) ogr2ogr -f MSSQLSpatial MSSQL:database=kn sample.gpkg sobr
>
> ->
>
> 1> select count(*) from sobr
> 2> go
>
> ---
>5437
>
> 2) ogr2ogr -f MSSQLSpatial -append MSSQL:database=kn sample.gpkg sobr
>
> ->
>
> 1> select count(*) from sobr
> 2> go
>
> ---
>   10874
>
> The same procedure fails for non-geometry layers:
>
> 1) ogr2ogr -f MSSQLSpatial MSSQL:database=kn sample.gpkg vla
>
> ->
>
> 1> select count(*) from vla
> 2> go
>
> ---
> 111
>
> 2) ogr2ogr -f MSSQLSpatial -append MSSQL:database=kn sample.gpkg vla
> ERROR 1: Error creating layer: [Microsoft][SQL Server Native Client
> 11.0][SQL Se
> rver]There is already an object named 'vla' in the database. When using
> the over
> write option and the layer doesn't contain geometry column, you might
> require to
>  use the MSSQLSPATIAL_LIST_ALL_TABLES config option to get the previous
> layer de
> leted before creating the new one.
> ERROR 1: Terminating translation prematurely after failed
> translation of layer VLA (use -skipfailures to skip errors)
>
> OK, let's try with MSSQLSPATIAL_LIST_ALL_TABLES
>
> 3) ogr2ogr -f MSSQLSpatial -append --config
> MSSQLSPATIAL_LIST_ALL_TABLES YES MSSQL:database=kn sample.gpkg vla
>
> Same error:
>
> ERROR 1: Error creating layer: [Microsoft][SQL Server Native Client
> 11.0][SQL Se
> rver]There is already an object named 'vla' in the database. When using
> the over
> write option and the layer doesn't contain geometry column, you might
> require to
>  use the MSSQLSPATIAL_LIST_ALL_TABLES config option to get the previous
> layer de
> leted before creating the new one.
> ERROR 1: Terminating translation prematurely after failed
> translation of layer VLA (use -skipfailures to skip errors)
>
> Number of records unchanged:
>
> 1> select count(*) from vla
> 2> go
>
> ---
> 111
>
> It seems to me as a bug, or is there anything I miss? Thanks for
> pointers, Martin
>
> --
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.cz/mentors/landa
> ___
> 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] Motion: promote GDAL 2.2.4 RC1 for release

[Tamas Szekeres]

+1

Tamas


2018-03-19 14:48 GMT+01:00 Even Rouault :

> Hi,
>
> (Combining both RC availability announcement and motion for vote)
>
> I have prepared a GDAL/OGR 2.2.4 release candidate. It fixes 42 issues
> since
> 2.2.3
>
> Peek up an archive among the following ones (by ascending size):
>
>   http://download.osgeo.org/gdal/2.2.4/gdal-2.2.4RC1.tar.xz
>   http://download.osgeo.org/gdal/2.2.4/gdal-2.2.4RC1.tar.gz
>   http://download.osgeo.org/gdal/2.2.4/gdal224RC1.zip
>
> A snapshot of the GDAL GRASS plugin is also available (unchanged since
> 2.2.0)
>
>   http://download.osgeo.org/gdal/2.2.4/gdal-grass-2.2.4RC1.tar.gz
>
> A snapshot of the gdalautotest suite is also available :
>
>   http://download.osgeo.org/gdal/2.2.4/gdalautotest-2.2.4RC1.tar.gz
>   http://download.osgeo.org/gdal/2.2.4/gdalautotest-2.2.4RC1.zip
>
> The NEWS file is here :
>
>   http://trac.osgeo.org/gdal/wiki/Release/2.2.4-News
>
> Note for packagers: I've compared the 2.2.3 and 2.2.4 sources and there's
> no
> change at all in the C or C++ API, so this should be (as expected) a
> drop-in
> replacement for GDAL 2.2.3 not requiring reverse dependencies to be
> rebuilt.
>
> ~
>
> Motion: promote GDAL 2.2.4 RC1 for release
>
> Starting with my +1
>
> --
> 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] Trac to GitHub

[Tamas Szekeres]

I don't think the trac tickets should be closed automatically. The ticket
owners should decide either to close (with a meaningful comment) or copy
it's variant to github if necessary.
I'm fine with option #2 and #4 and preserving/updating the history would be
a plus, but not a necessary requirement.

Best regards,

Tamas



2018-03-19 14:25 GMT+01:00 Even Rouault :

> Hi,
>
> Adding gdal-dev into the loop to get more feedback.
>
> I actually discussed about that with Howard yesterday, and he suggested an
> even easier and least-effort solution. Do we actually need to migrate the
> existing Trac ticket database to github ?
>
> If not, we could just freeze Trac as read-only and decide that we just open
> the github repo for tickets...
> What would be nice to do is to rewrite a bit the git history of the current
> mirror so that commit messages like "Fix blabla (fixes #1234)" as
> rewritten as
> "Fix blabla (fixes https://trac.osgeo.org/gdal/ticket/1234)"
>
> A more complicated version of the above is that we would migrate only the
> open
> Trac tickets to github (so < 600 instead of 6000). And we would add in each
> open Trac ticket a message like "This ticket has been migated to https://
> github.com/OSGeo/gdal/issue/4567", and close it. But that requires still
> some
> migration effort and deal with github API.
> A simpler variant of the above would be just close all those open tickets,
> assigning them to some milestone "closed-before-github-migration" with a
> message "Issue reporting has now been migrated to
> https://github.com/OSGeo/
> gdal/issues. If that issue is still valid, please file a ticket over
> there".
> That can be done simply in a few seconds from Trac UI with a "batch
> modifiy"
> action.
>
> So to sum up my thoughts would be to:
> 1) Rewrite the github history (still need to figure out how to automate
> that)
> to fix references to Trac ticket, and force-push the result to github.com/
> OSGeo/gdal. Note: that would invalidate current forks, so people with
> active
> work would probably have to rebase or to export as a patch and re-apply on
> top
> of updated Git repository.
> 2) Open github for filing tickets
> 3) Close all Trac tickets with assignment to a "closed-before-github-
> migration" milestone, and a message "Issue reporting has now been migrated
> to
> https://github.com/OSGeo/gdal/issues...;
> 4) Remove TICKET_CREATE rights to authenticated users of Trac
>
> Does that sound good ?
>
> Even
>
>
> On lundi 19 mars 2018 11:48:15 CET Mateusz Loskot wrote:
> > Hi Even,
> [...]
> > I've just pushed some basic stab at exporting Trac to GitHub
> > which I started prototyping in the beginning of October last year
> > https://github.com/mloskot/trac-to-github
> >
> > In October, Paul Ramsey released his bunch of scripts
> > https://github.com/pramsey/postgis-to-github/
> > which, I think, cover the procedure more completely
> > and it's also based on GitHub API.
> > Shortly, instead of continue my development, Paul's solution may be
> > the way to go.
> > I haven't tried to run Paul's scripts, so I don't know what technically
> > is stopping the PostGIS migration, if anything.
> >
> > Generally, I think GitHub API approach is the way to go.
> > Annoyingly, the rate limits seem to lead to strange issues that I
> > experienced (eg. adding or adding 30 labels, some are left over).
> > This confirms what Thomas Bonfort was warning about and suggesting
> > to reach out to GitHub support stating you are running a batch import.
> >
> > I don't if Paul reached to GitHub support before performing PostGIS test
> > import https://github.com/pramsey/postgis-gh/issues
> > but it looks that a few thousands of tickets made it through.
> >
> > I've taken the liberty to CC to Paul perhaps he could shed more light.
> [...]
> >
> > Best regards,
>
>
> --
> 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] Motion: Adopt RFC 70: Guessing output format from output file name extension

[Tamas Szekeres]

+1

Best regards,

Tamas



2017-11-15 16:07 GMT+01:00 Even Rouault :

> Hi,
>
>
>
> I move to adopt RFC 70: Guessing output format from output file name
> extension
>
>
>
> https://trac.osgeo.org/gdal/wiki/rfc70_output_format_guess
>
>
>
> Starting with my +1,
>
>
>
> Best regards,
>
>
>
> 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] gdalwarp from C#

[Tamas Szekeres]

Would Gdal.ReprojectImage do what you want in this particular case? This is
the signature that can be used in the C# bindings:

*public static CPLErr ReprojectImage(Dataset src_ds, Dataset dst_ds, string
src_wkt, string dst_wkt, ResampleAlg eResampleAlg, double WarpMemoryLimit,
double maxerror, Gdal.GDALProgressFuncDelegate callback, string
callback_data, string[] options)*

Best regards,

Tamas

2017-11-04 20:04 GMT+01:00 Karu Kaarigar :

> I am trying to use gdalwarp using C# bindings. I am using 64bit libs.
> However, I am not able to find proper docs on its usage. Specifically I
> need to know how to use the GDALWarpAppOptions and the format of options
> string array passed to its constructor. I also need to know the call
> semantics of various wrapper methods (wrapper_GDALWarpDestName,
> wrapper_GDALWarpDestName). I m confused about its arguments such as
> SWIGTYPE_p_p_GDALDatasetShadow, etc.
>
> Any help or pointers is highly appreciated. Is there any sample code that
> shows how to use gdalwarp from C#? Thanks you.
>
> ___
> 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] Motion: grant commit rights to Alan Thomas

[Tamas Szekeres]

+1

Tamas

2017-11-01 10:48 GMT+01:00 Even Rouault :

> Hi PSC,
>
>
>
> Alan has done in the last months a lot of great work (fixes and
> improvements) in the DXF driver, including adding new test cases and
> updating documentation when needed:
>
> https://trac.osgeo.org/gdal/ticket/7111
>
> https://trac.osgeo.org/gdal/ticket/7106
>
> https://trac.osgeo.org/gdal/ticket/7098
>
> https://trac.osgeo.org/gdal/ticket/7105
>
> https://trac.osgeo.org/gdal/ticket/7099
>
> https://trac.osgeo.org/gdal/ticket/7089
>
> https://trac.osgeo.org/gdal/ticket/7038
>
> https://trac.osgeo.org/gdal/ticket/7006
>
> https://trac.osgeo.org/gdal/ticket/6971
>
>
>
> And there are more to come:
>
> https://trac.osgeo.org/gdal/ticket/7120
>
> https://trac.osgeo.org/gdal/ticket/7121
>
> https://trac.osgeo.org/gdal/ticket/7122
>
>
>
> So it would be more convenient to grant him direct commit rights.
>
>
>
> 
>
>
>
> Motion: grant commit rights to Alan Thomas
>
>
>
> +1 Even
>
>
>
> ~
>
>
>
> Alan, could you reply to the list confirming that you agree on
>
> https://trac.osgeo.org/gdal/wiki/rfc3_commiters
>
>
>
> Best regards,
>
>
>
> 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] Get WFS attributes form the gml namespace as OGR fields

[Tamas Szekeres]

Hi Even,

Thank you, that could indeed solve the problem.

Best regards,

Tamas


2017-10-20 0:10 GMT+02:00 Even Rouault <even.roua...@spatialys.com>:

> On jeudi 19 octobre 2017 23:56:29 CEST Tamas Szekeres wrote:
> > It looks like DOWNLOAD_SCHEMA=NO would do the trick, but if I use this
> in a
> > VRT file this way it crashes GDAL.
>
> Just fixed the crash (related to the HTTP driver and GDAL_OF_SHARED open
> flag)
>
> You can also prefix the URL with /vsicurl_streaming/ to avoid full
> ingestion
> into memory
>
> >
> > 
> > 
> > 
> > http://cstest.coordinatesolutions.com/geoserver/wfs?VERSION=1.1.0;
> amp;REQUES
> > T=GetFeatureTYPENAME=ogi:okcountiesSRSNAME=EPSG:900913
> > 
> > 
> > NO
> > 
> > EPSG:900913
> > SELECT *,
> > 'BRUSH(fc:#);PEN(c:#008000,w:3px);LABEL(f:"Arial",
> c:#008000,s:14px,t
> > :{name})' as OGR_STYLE from "okcounties"
> > 
> > 
> >
> > 2017-10-19 23:18 GMT+02:00 Even Rouault <even.roua...@spatialys.com>:
> > > On jeudi 19 octobre 2017 22:55:50 CEST Tamas Szekeres wrote:
> > > > Hi all,
> > > >
> > > > It looks like whenever we have a dataset (shapefile,db table,etc...)
> > >
> > > which
> > >
> > > > has a
> > > > column with such names like "description", "name", "location"
> GeoServer
> > > > maps it to the elements in the gml namespace (in a 1.1 request),
> > > > therefore DescribeFeatureType doesn't contain these attributes.
> > > >
> > > > For example this response doesn't include the name attribute
> > > >
> > > > http://cstest.coordinatesolutions.com/geoserver/wfs?VERSION=1.1.0;
> > >
> > > SERVICE=WF
> > >
> > > > S=DescribeFeatureType=ogi:okcounties
> > > >
> > > > However that attribute is returned in the GetFeature request in the
> > > > gml:name section, like:
> > > >
> > > > http://cstest.coordinatesolutions.com/geoserver/wfs?VERSION=1.1.0;
> > >
> > > REQUEST=Ge
> > >
> > > > tFeature=ogi:okcounties
> > > >
> > > > But as the result of this behaviour the WFS driver doesn't include
> this
> > > > item in the layer definition. Is that possible to retrieve these
> > >
> > > attributes
> > >
> > > > from the WFS driver as OGR fields for example to use them in SQL
> > > > expressions?
> > >
> > > Hi Tamas,
> > >
> > > If your need is to filter on the server, then you'll need to compose
> the
> > > full
> > > URL at hand.
> > > If you want to post-filter, you can downloader the GetFeature request
> and
> > > open
> > > the GML file with the DOWNLOAD_SCHEMA=NO open option (or
> > > GML_DOWNLOAD_WFS_SCHEMA=NO configuration option)
> > > This will prevent the GML driver from trying to use the schema, and
> then
> > > it
> > > will discover the gml:name element.
> > >
> > > OGRFeature(okcounties):155
> > >
> > >   gml_id (String) = okcounties.155
> > >   name (String) = BEAVER
> > >   state (Integer) = 40
> > >   county (Integer) = 7
> > >   stateplane (String) = N
> > >   MULTIPOLYGON (((-100.945566 )))
> > >
> > > The XSD parser used by the WFS and GML drivers could also possibly be
> > > modified
> > > to hard-code the definition of those few GML fields (although they
> might
> > > depend on the GML version).
> > >
> > >
> > > Otherwise you can also use the GMLAS driver, but the result will be a
> bit
> > > inconvenient to use as it will create a dedicated layer for the name
> > > attribute
> > > (as gml:name can be repeated):
> > >
> > > $ ogrinfo GMLAS:out.xml
> > > INFO: Open of `GMLAS:out.xml'
> > >
> > >   using driver `GMLAS' successful.
> > >
> > > 1: okcounties (Multi Surface)
> > > 2: okcounties_metadataproperty (None)
> > > 3: okcounties_name (None)
> > > 4: location (None)
> > >
> > > OGRFeature(okcounties):1
> > >
> > >   ogr_pkid (String) = 213FC01A8AA5FA1E1ADC65B21904DA34_okcounties_1
> > >   id (String) = okcounties.155
> > >   state (Integer64) = 40
> > >   county (Integer64) = 7
> > >   stateplane (String) = N
> > >   MULTIPOLYGON (((-100.945566)))
> > >
> > > OGRFeature(okcounties_name):1
> > >
> > >   ogr_pkid (String) = 213FC01A8AA5FA1E1ADC65B21904DA
> 34_okcounties_1_name_1
> > >   parent_ogr_pkid (String) = 213FC01A8AA5FA1E1ADC65B21904DA
> 34_okcounties_1
> > >   value (String) = BEAVER
> > >
> > > Even
> > >
> > >
> > > --
> > > Spatialys - Geospatial professional services
> > > http://www.spatialys.com
>
>
> --
> 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] Get WFS attributes form the gml namespace as OGR fields

[Tamas Szekeres]

It looks like DOWNLOAD_SCHEMA=NO would do the trick, but if I use this in a
VRT file this way it crashes GDAL.




http://cstest.coordinatesolutions.com/geoserver/wfs?VERSION=1.1.0REQUEST=GetFeatureTYPENAME=ogi:okcountiesSRSNAME=EPSG:900913


NO

EPSG:900913
SELECT *,
'BRUSH(fc:#);PEN(c:#008000,w:3px);LABEL(f:"Arial",c:#008000,s:14px,t:{name})'
as OGR_STYLE from "okcounties"







2017-10-19 23:18 GMT+02:00 Even Rouault <even.roua...@spatialys.com>:

> On jeudi 19 octobre 2017 22:55:50 CEST Tamas Szekeres wrote:
> > Hi all,
> >
> > It looks like whenever we have a dataset (shapefile,db table,etc...)
> which
> > has a
> > column with such names like "description", "name", "location" GeoServer
> > maps it to the elements in the gml namespace (in a 1.1 request),
> > therefore DescribeFeatureType doesn't contain these attributes.
> >
> > For example this response doesn't include the name attribute
> >
> > http://cstest.coordinatesolutions.com/geoserver/wfs?VERSION=1.1.0;
> SERVICE=WF
> > S=DescribeFeatureType=ogi:okcounties
> >
> > However that attribute is returned in the GetFeature request in the
> > gml:name section, like:
> >
> > http://cstest.coordinatesolutions.com/geoserver/wfs?VERSION=1.1.0;
> REQUEST=Ge
> > tFeature=ogi:okcounties
> >
> > But as the result of this behaviour the WFS driver doesn't include this
> > item in the layer definition. Is that possible to retrieve these
> attributes
> > from the WFS driver as OGR fields for example to use them in SQL
> > expressions?
>
> Hi Tamas,
>
> If your need is to filter on the server, then you'll need to compose the
> full
> URL at hand.
> If you want to post-filter, you can downloader the GetFeature request and
> open
> the GML file with the DOWNLOAD_SCHEMA=NO open option (or
> GML_DOWNLOAD_WFS_SCHEMA=NO configuration option)
> This will prevent the GML driver from trying to use the schema, and then it
> will discover the gml:name element.
>
> OGRFeature(okcounties):155
>   gml_id (String) = okcounties.155
>   name (String) = BEAVER
>   state (Integer) = 40
>   county (Integer) = 7
>   stateplane (String) = N
>   MULTIPOLYGON (((-100.945566 )))
>
> The XSD parser used by the WFS and GML drivers could also possibly be
> modified
> to hard-code the definition of those few GML fields (although they might
> depend on the GML version).
>
>
> Otherwise you can also use the GMLAS driver, but the result will be a bit
> inconvenient to use as it will create a dedicated layer for the name
> attribute
> (as gml:name can be repeated):
>
> $ ogrinfo GMLAS:out.xml
> INFO: Open of `GMLAS:out.xml'
>   using driver `GMLAS' successful.
> 1: okcounties (Multi Surface)
> 2: okcounties_metadataproperty (None)
> 3: okcounties_name (None)
> 4: location (None)
>
> OGRFeature(okcounties):1
>   ogr_pkid (String) = 213FC01A8AA5FA1E1ADC65B21904DA34_okcounties_1
>   id (String) = okcounties.155
>   state (Integer64) = 40
>   county (Integer64) = 7
>   stateplane (String) = N
>   MULTIPOLYGON (((-100.945566)))
>
> OGRFeature(okcounties_name):1
>   ogr_pkid (String) = 213FC01A8AA5FA1E1ADC65B21904DA34_okcounties_1_name_1
>   parent_ogr_pkid (String) = 213FC01A8AA5FA1E1ADC65B21904DA34_okcounties_1
>   value (String) = BEAVER
>
>
> 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] Get WFS attributes form the gml namespace as OGR fields

[Tamas Szekeres]

Hi all,

It looks like whenever we have a dataset (shapefile,db table,etc...) which
has a
column with such names like "description", "name", "location" GeoServer
maps it to the elements in the gml namespace (in a 1.1 request),
therefore DescribeFeatureType doesn't contain these attributes.

For example this response doesn't include the name attribute

http://cstest.coordinatesolutions.com/geoserver/wfs?VERSION=1.1.0=WFS=DescribeFeatureType=ogi:okcounties

However that attribute is returned in the GetFeature request in the
gml:name section, like:

http://cstest.coordinatesolutions.com/geoserver/wfs?VERSION=1.1.0=GetFeature=ogi:okcounties

But as the result of this behaviour the WFS driver doesn't include this
item in the layer definition. Is that possible to retrieve these attributes
from the WFS driver as OGR fields for example to use them in SQL
expressions?

Thanks,

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

Re: [gdal-dev] /MD vs /MDd for DEBUG MSVC builds

[Tamas Szekeres]

I'd like to see /Od  in addition to the /Zi and /MD etc. with the
DEBUG_WITH_RELEASE_CRT
setting. By this means it's not the same as RelWithDebInfo which uses /O2
as far as I remember, which was the only setting that I always have to
change with the cmake builds to make it usable for debugging purposes.

Best regards,

Tamas


2017-10-16 23:55 GMT+02:00 Even Rouault :

> >
> > That would not be equivalent to CMake RelWithDebugInfo, which is is
> pretty
> > self-descriptive. Here is explanation from
> > https://cmake.org/pipermail/cmake/2001-October/002479.html
> >
> >
> > "The difference between Debug and RelwithDebInfo is that RelwithDebInfo
> is
> > quite similar to Release mode. It produces fully optimised code, but also
> > builds the program database, and inserts debug line information..."
> >
> > Or, I'm m being unclear about use of /DEBUG
>
> I didn't check CMake semantics. Hum, then what about calling it
> DEBUG_WITH_RELEASE_CRT=1 ?
>
>
>
> --
> 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] /MD vs /MDd for DEBUG MSVC builds

[Tamas Szekeres]

Looks like I've missed this thread earlier, but according to this change we
might either compile all the dependent libraries for /MDd (at least for the
statically linked libraries) or we trust in that GDAL is safe to compile
against a different CRT than the dependencies. That means that GDAL won't
free up memory that have been allocated in either of the dependencies or
vica versa. I'm not completely sure if the latter applies.

The earlier approach was a bit more like the RelWithDebInfo setting in the
cmake terminology which is not considered as a wrong setting, but that has
it's own purpose. At the moment I'm not aware of any binary distributions
or SDKs out of the box which would be compatible with the /MDd setting,
that causes that DEBUG=1 has a fairly limited usability from now on.

Best regards,

Tamas



2017-09-28 12:05 GMT+02:00 Even Rouault :

> Hi,
>
>
>
> Given the feedback, I've just committed the below change (in trunk only)
>
>
>
> Even
>
>
>
> >
>
> > $ svn diff nmake.opt
>
> > Index: nmake.opt
>
> > ===
>
> > --- nmake.opt (revision 40206)
>
> > +++ nmake.opt (working copy)
>
> > @@ -132,13 +132,13 @@
>
> > !IFNDEF DEBUG
>
> > OPTFLAGS= $(CXX_ANALYZE_FLAGS) $(CXX_PDB_FLAGS) /nologo /MP /MD /EHsc /Ox
>
> > /FC /D_CRT_SECURE_NO_DEPRECATE /D_CRT_NONSTDC_NO_DEPRECATE /DNDEBUG !ELSE
>
> > -OPTFLAGS= $(CXX_ANALYZE_FLAGS) $(CXX_PDB_FLAGS) /nologo /MP /MD /EHsc
> /FC
>
> > /D_CRT_SECURE_NO_DEPRECATE /D_CRT_NONSTDC_NO_DEPRECATE /DDEBUG +OPTFLAGS=
>
> > $(CXX_ANALYZE_FLAGS) $(CXX_PDB_FLAGS) /nologo /MP /MDd /EHsc /FC
>
> > /D_CRT_SECURE_NO_DEPRECATE /D_CRT_NONSTDC_NO_DEPRECATE /DDEBUG !ENDIF
>
> > !ELSE
>
> > !IFNDEF DEBUG
>
> > OPTFLAGS= $(CXX_PDB_FLAGS) /nologo /MD /EHsc /GR /Ox /FC /DNDEBUG
>
> > !ELSE
>
> > -OPTFLAGS= $(CXX_PDB_FLAGS) /nologo /MD /EHsc /GR /FC /DDEBUG
>
> > +OPTFLAGS= $(CXX_PDB_FLAGS) /nologo /MDd /EHsc /GR /FC /DDEBUG
>
> > !ENDIF
>
> > !ENDIF #MSVC_VER
>
> > !ENDIF # OPTFLAGS
>
> >
>
>
>
> --
>
> 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] 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, GeoServer with JIRA for tickets and github for PR
> 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 

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 <szeker...@gmail.com>:

> 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] 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] 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 
> 

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] 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] 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: Promote 2.1.0RC4 for release

[Tamas Szekeres]

+1

Tamas

2016-04-27 10:18 GMT+02:00 Even Rouault :

> Motion: GDAL/OGR 2.1.0RC4 is promoted to be the official 2.1.0 final
> release.
>
> ---
>
> +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] Shapefile to SQL Server

[Tamas Szekeres]

Hi,

Looks like you have invalid latitude values in the shapefile. Try creating
geometry type instead of geography.

Best regards,

Tamas



2016-04-15 17:06 GMT+02:00 Mike Colbert :

> Hi,
>
>
>
> I have a Java web app with a SQL Server database and I would like to add
> support for importing shapefiles.  The shapes will then be used to
> determine if geographic locations we have defined in our system are within
> the areas defined by the shapes.
>
>
>
> I’ve gone down the path of using ogr2ogr from Java to connect to SQL
> Server and load the shapefile.  However, I’m getting an error on a
> particular file I will need to load.  I’m wondering if I’m missing an
> option on the command?  Using a different shapefile, it seems to work.
>
>
>
> Here is the command and the error:
>
>
>
> String[] cmd = {
>
> "-overwrite",
>
> "-f", "MSSQLSpatial",
>
>
> "MSSQL:Server=xxx;Database=xxx;Uid=xxx;Pwd=xxx",
>
>
> "C:\\Users\\mcolbert\\Downloads\\UGRB_Ozone_NAA\\UGRB_Ozone_NAA.shp", //
> error on this one
>
> //
> "C:\\Users\\mcolbert\\Downloads\\tl_2010_06_zcta510\\tl_2010_06_zcta510.shp",
> // this one seems fine
>
> "-lco", "GEOM_TYPE=geography",
>
> "-lco", "GEOM_NAME=geog",
>
> "-nln", "CM_SHAPE",
>
> "--debug", "ON"
>
> //,"-a_srs", "ESPG:4269"
>
> };
>
> ogr2ogr.main(cmd);
>
>
>
> OGR:
> OGROpen(C:\Users\mcolbert\Downloads\UGRB_Ozone_NAA\UGRB_Ozone_NAA.shp/003FFE40)
> succeeded as ESRI Shapefile.
>
> OGR_MSSQLSpatial:
> EstablishSession(Connection:"Server=xxx;Database=xxx;Uid=xxx;Pwd=xxx")
>
> ODBC: SQLDriverConnect(DRIVER=SQL
> Server;Server=xxx;Database=xxx;Uid=xxx;Pwd=xxx)
>
> OGR:
> OGROpen(MSSQL:Server=xxx;Database=xxx;Uid=xxx;Pwd=xxx/0042C440)
> succeeded as MSSQLSpatial.
>
> MSSQLSpatial: DeleteLayer(cm_shape)
>
> OGR_MSSQLSpatial: Using column ogr_fid as FID for table cm_shape.
>
> ERROR 1: INSERT command for new feature failed. [Microsoft][ODBC SQL
> Server Driver][SQL Server]A .NET Framework error occurred during execution
> of user-defined routine or aggregate "geography":
>
>
>
> System.FormatException: 24201: Latitude values must be between -90 and 90
> degrees.
>
>
>
> System.FormatException:
>
>
>
>at Microsoft.SqlServer.Types.GeographyValidator.ValidatePoint(Double x,
> Double y, Nullable`1 z, Nullable`1 m)
>
>
>
>at Microsoft.SqlServer.Types.Validator.BeginFigure(Double x, Double y,
> Nullable`1 z, Nullable`1 m)
>
>
>
>at Microsoft.SqlServer.Types.Forw
>
> Terminating translation prematurely after failed
>
> translation of layer UGRB_Ozone_NAA (use -skipfailures to skip errors)
>
>
>
>
>
>
>
> I’m assuming there is nothing unusual about the shapefile.  The file is
> available here:
>
>
> http://deq.wyoming.gov/media/attachments/Air%20Quality/Winter%20Ozone/Nonattainment%20Information/2012_AQD_UGRB-Ozone-Nonattainment-Area-GIS-Shape-File.zip
>
>
>
> Any help is appreciated.
>
>
>
> Thanks,
>
> Mike
>
>
>
>
>
>
>
>
>
>
>
> ___
> 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 packaging in OSGeo4W

[Tamas Szekeres]

Hi Jürgen,

Is that possible to include further plugins in the gdal-dev build?
I'm interested in adding the new ogr_MSSQLSpatial.dll plugin build as an
optional component? Though it requires the SQL Server native client 11
driver installed on the build machine. I could add this package manually,
but I'm not sure if that satisfies with the intent that these are nightly
build packages. Since this plugin depends on sqlncli11.dll the package
description should mention the requirement to install the SQL Server native
client 11 driver as a prerequisite.

in nmake.opt the followings should be enabled when compiling the plugin:
SQLNCLI_VERSION = 11
SQLNCLI_DIR = C:\Program Files (x86)\Microsoft SQL
Server\$(SQLNCLI_VERSION)0\SDK
SQLNCLI_LIB = "$(SQLNCLI_DIR)\Lib\x86\sqlncli$(SQLNCLI_VERSION).lib"
SQLNCLI_INCLUDE = "-I$(SQLNCLI_DIR)\Include"
-DSQLNCLI_VERSION=$(SQLNCLI_VERSION) -DMSSQL_BCP_SUPPORTED=1


Thanks,

Tamas



2016-04-06 18:37 GMT+02:00 Jürgen E. :

> Hi Even,
>
> On Mon, 22. Feb 2016 at 12:15:31 +0100, Even Rouault wrote:
> > Could be cool to have -dev versions packaged from time to time (or
> potentially
> > nightly builds), as well as a few drivers available as plugins (PDF
> driver,
> > MongoDB one)
>
> There's a nighly build of GDAL in OSGeo4W now.   Invoke gdal-dev-env from
> the
> osgeo4w shell to setup it's paths.
>
>
> Jürgen
>
> --
> Jürgen E. Fischer norBIT GmbH   Tel.
> +49-4931-918175-31
> Dipl.-Inf. (FH)   Rheinstraße 13Fax.
> +49-4931-918175-50
> Software Engineer D-26506 Norden
> http://www.norbit.de
>
> ___
> 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 2.1 release plans

[Tamas Szekeres]

Hi Even,

I'm working on the bulk insert option for the MSSQL driver which should be
included in this release. This makes the upload ~20 times faster. Most of
the implementation is already done, but there are some further issues which
should be fixed before adding that part in the codebase.

Best regards,

Tamas


Even Rouault  ezt írta (2016. március 1., kedd):

> Le lundi 29 février 2016 22:19:03, Sean Gillies a écrit :
> > On Fri, Jan 15, 2016 at 7:11 AM, Even Rouault <
> even.roua...@spatialys.com >
> >
> > wrote:
> > > Hi,
> > >
> > > As I've received lately a few emails asking me about GDAL 2.1, it's
> time
> > > to discuss that publicly.
> > >
> > > To keep roughly with our yearly cycle, I think we could probably
> target a
> > > beta
> > > 1 for the beginning of April, with possibly the release happening end
> > > April/beginning May if things go well (optimistic scenario : 3 weeks
> for
> > > betas
> > > + 1 week RCs).
> > >
> > > Opinions ? Any candidate for being release manager ?
> > >
> > > Cheers,
> > >
> > > Even
> >
> > I wish I could raise my hand for the release manager job, but I'm pretty
> > tied up with the GeoJSON WG.
> >
> > I like the time frame you've proposed. There's some work in progress I'd
> > like to see in 2.1 (https://github.com/OSGeo/gdal/pull/98) and 4 weeks
> > should be enough to finish it.
>
> Hi,
>
> I intend to cut a 2.1.0 beta1 release on March 31st, which will be the
> feature
> freeze and start point of the 2.1 branch.
>
> For everybody information, are there major pieces of work (other than the
> above mentionned one) that are expected to land in trunk during this month
> ?
>
> Regarding M support, the following drivers have been updated : Shapefile,
> PostGIS, MEM, FileGDB, OpenFileGDB, CSV, VRT, GeoPackage,
> SQLite/Spatialite.
> (Personal Geodatabase should probably work too, but untested). As well as
> ogrinfo / ogr2ogr. Earlier testers appreciated.
>
> 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] RFC 61: Call for vote on adoption

[Tamas Szekeres]

+1

I'll update the mssql spatial driver accordingly.

Best regards,

Tamas


2016-02-05 9:04 GMT+01:00 Ari Jolma :

> I'd like to ask the PSC and others to vote on adopting RFC 61:  Support
> for measured geometries.
>
> The draft RFC is at
>
> https://trac.osgeo.org/gdal/wiki/rfc61_support_for_measured_geometries
>
> and a draft implementation is at
>
> https://github.com/ajolma/GDAL-XYZM
>
> which is tested at
>
> https://travis-ci.org/ajolma/GDAL-XYZM
>
> (the test #34, which passed, was the so far last one after core changes
> with unchanged autotests and a rather comprehensive set of WKT tests in the
> Perl tests directory)
>
> This is seemingly a small change but it is at the heart of OGR so it has
> some important implications. The only backwards incompatibilities that have
> appeared so far are with some drivers, for example shapefile, which can be
> lessened with, e.g., open options.
>
> Best,
>
> Ari
>
>
> ___
> 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] Issue with c# bindings

[Tamas Szekeres]

Hi Kelly,

It looks like you are compiling against .Net 4 and the /define:CLR4 is
missing from the csc command line. Also make sure the following line is
added to AssemblyInfo.cs when compiling the assemblies:

[assembly: SecurityRules(SecurityRuleSet.Level1)]


Best regards,

Tamas



2015-12-09 23:02 GMT+01:00 kelly elton :

> I'm getting this error after compiling from source
>
> Exception thrown: 'System.MethodAccessException' in gdal_csharp.dll
>
> Additional information: Attempt by security transparent method
> 'OSGeo.GDAL.Gdal.UseExceptions()' to call native code through method
> 'OSGeo.GDAL.GdalPINVOKE.UseExceptions()' failed.  Methods must be security
> critical or security safe-critical to call native code.
>
> I did
> nmake -f makefile.vc clean && nmake -f makefile.vc MSVC_VER=1600 DEBUG=1
> && nmake -f makefile.vc install
> cd swig
> nmake -f makefile.vc csharp
>
> I get the gdal dll + the csharp dlls...and I use them
>
> But as soon as I call OSGeo.GDAL.Gdal.UseExceptions(); I get the exception
>
> This doesn't happen with the dll's I've downloaded from
> http://www.gisinternals.com/
>
> I got the source from https://trac.osgeo.org/gdal/wiki/DownloadSource and
> I got 2.0.1
>
> ___
> 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 to David Adler

[Tamas Szekeres]

+1

Tamas


2015-12-02 23:04 GMT+01:00 Mateusz Loskot :

> Motion: Committer Status for David Adler
> ---
>
> Dear PSC,
>
> David is preparing contribution of new OGR driver for DB2 [1].
> I would like to propose motion to grant the SVN commit access to David
> Adler.
> This will help David to support any new features or changes
> and allow 'streamline' maintenance of the DB2 driver.
> David has demonstrated necessary knowledge of GDAL/OGR code base,
> despite the new driver currently targets Windows platform, he is willing to
> continue development and support targeting Linux as well.
>
> David is a very experienced developer, specialised in IBM DB2 technologies.
> I have met David in person some time ago.
>
> I'm not a PSC member, but in this particular case I feel eligible to start
> voting with symbolic +1.
>
>
> David,
> Please, could you answer to this very message and state that you have
> read and agreed to the committer guidelines as outlined in the RFC3 [2].
>
>
> [1] https://trac.osgeo.org/gdal/ticket/6191
> [2] http://trac.osgeo.org/gdal/wiki/rfc3_commiters
>
> Best regards,
> --
> Mateusz Loskot, http://mateusz.loskot.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: Adopt RFC 60: Improved round-tripping in OGR

[Tamas Szekeres]

+1

Tamas

2015-11-04 18:32 GMT+01:00 Even Rouault :

> Hi,
>
> Since no remarks have been done on the latest proposal, I move to adopt RFC
> 60 : Improved round-tripping in OGR
>
> https://trac.osgeo.org/gdal/wiki/rfc60_improved_roundtripping_in_ogr
>
> 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: Adopt FRC48: Geographical networks support

[Tamas Szekeres]

+1

Tamas

2015-07-17 12:09 GMT+02:00 Dmitry Baryshnikov bishop@gmail.com:

 Hi,

 I finished the work on merging the GSoC2014  Geographical networks support
 in GDAL to trunk.
 The RFC (
 https://trac.osgeo.org/gdal/wiki/rfc48_geographical_networks_support) was
 corrected.
 The pull request (https://github.com/OSGeo/gdal/pull/60) created.
 Travis building passed.

 I think it's time to vote for adopt the RFC 48 Geographical networks
 support and to merge the pull request to the GDAL sources trunk. According
 to https://trac.osgeo.org/gdal/wiki/rfc1_pmc I start the vote and my +1
 for adopt.

 --
 Best regards,
 Dmitry

 ___
 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: Adopt RFC 26: GDAL Block Cache Improvements

[Tamas Szekeres]

A belated +1 here. As being the initial author, I'm happy to get it
implemented.

2015-06-19 9:52 GMT+02:00 Even Rouault even.roua...@spatialys.com:

 Hi,

 As no points have been raised on the RFC:

 Motion : I move to adopt RFC 26: GDAL Block Cache Improvements

 https://trac.osgeo.org/gdal/wiki/rfc26_blockcache

 Starting with my +1

 Best regards,

 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.0.0RC2 for release

[Tamas Szekeres]

+1

Tamas

2015-06-18 11:26 GMT+02:00 Even Rouault even.roua...@spatialys.com:

 Le mardi 16 juin 2015 10:02:37, Even Rouault a écrit :
  Motion: GDAL/OGR 2.0.0RC2 is promoted to be the official 2.0.0 final
  release.
 
  ---
 
  No critical issue has been reported on RC2 so far, so I invite PSC
  members to vote on this motion after doing your own testing and
 validation.
  Input from everyone else who can test it is also very welcome.
 
  I'll start the voting with my :
 
  +1 Even

 Technically, there's only +1 from Jukka and myself on this motion after 2
 business days. I'd appreciate more votes from other PSC members.

 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] CSharp bindings question

[Tamas Szekeres]

Hi Asa,

Thanks for the detailed investigation, I'll evaluate the result of the
changes and try to incorporate them in GDAL.

Best regards,

Tamas



2015-06-10 20:07 GMT+02:00 Asa Packer apac...@biosonicsinc.com:

 Hello again,

 Sorry, I posted this using the Nabble gateway, and the text I formatted as
 raw text did not come through correctly in email.  Here is another try.

 -Asa
 ---
 Hello,

 I am new to GDAL, and SWIG.  I spent yesterday getting GDAL 1.11.2 compiled
 and ran into similar errors trying to build the C# bindings as are being
 discussed on this thread.  I am on Windows (7 Pro SP1 x64) using Visual
 Studio 2013's command prompt.  I am using the current version of swigwin,
 3.0.5.

 FWIW, I was able to fix the errors by making the following changes.  Since
 I
 don't really understand what SWIG is doing very well, I'm not sure how safe
 these are, although they seem fairly minor.  I apologize if this has
 already
 been discussed somewhere else - I'm reporting them just in case they are
 helpful.

 1. Change line 95 of
 gdal-1.11.2/swig/include/csharp/swig_csharp_extensions.i from
   public $csclassname(IntPtr cPtr, bool cMemoryOwn, object parent) :
 base($modulePINVOKE.$csclassnameUpcast(cPtr), cMemoryOwn, parent) {
 to
   public $csclassname(IntPtr cPtr, bool cMemoryOwn, object parent) :
 base($modulePINVOKE.$csclassname_SWIGUpcast(cPtr), cMemoryOwn, parent) {

 This fixes errors saying that the upcast function does not exist.  These
 errors happen starting with SWIG 2.0.0.

 2. Delete lines 12-17 of
 gdal-1.11.2/swig/include/csharp/swig_csharp_extensions.i - this fixes the
 duplicate static constructor error CS0111.  This error is related to the
 following entry from the SWIG changelog
 http://www.swig.org/Release/CHANGES.
 The change was first released in SWIG 2.0.0.

 2010-05-23: wsfulton
 [C#] Fix #2957375 - SWIGStringHelper and SWIGExceptionHelper
 not
 always being
 initialized before use in .NET 4 as the classes were not marked
 beforefieldinit.
 A static constructor has been added to the intermediary class
 like this:

   %pragma(csharp) imclasscode=%{
 static $imclassname() {
 }
   %}

 If you had added your own custom static constructor to the
 intermediary class in
 the same way as above, you will have to modify your approach to
 use static variable
 initialization or define
 SWIG_CSHARP_NO_IMCLASS_STATIC_CONSTRUCTOR - See csharphead.swg.

 *** POTENTIAL INCOMPATIBILITY ***

 3. Add the -DSWIG2_CSHARP flag to my SWIG variable in
 gdal-1.11.2/nmake.local.  This fixes numerous errors about basic .NET types
 like IntPtr not being defined.  This is related to the following entry from
 the SWIG changelog, first released in version 3.0.0:

 2013-11-09: wsfulton
 [C#] Apply patch #79 from Brant Kyser
   - Remove using directives from the generated C# code and
 fully
 qualify the use of all .NET
 framework types in order to minimize potential name
 collisions from input files defining
 types, namespace, etc with the same name as .NET framework
 members.
   - Globally qualify the use of .NET framework types in the
 System namespace
   - Remove .NET 1.1 support, .NET 2 is the minimum for the C#
 module

 This is a potential backwards compatibility break if code has
 been added relying on these using
 statements that used to be generated:

   using System;
   using System.Runtime.InteropServices;

 The quick fix to add these back in is to add the -DSWIG2_CSHARP
 command line option when
 executing SWIG. See CSharp.html documentation for more info.

 *** POTENTIAL INCOMPATIBILITY  ***

 Thanks!  I appreciate all the work that you and others have done to make
 GDAL so nice.

 Asa


 ___
 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] Bindings

[Tamas Szekeres]

Hi Ari,

Creating language specific main files would be fine for me. We could also
add the language specific extensions at the bottom section (like
gdal_csharp_extend.i) directly into the file.

We should however make sure to update all relevant files if a common change
is done in a language specific file.

Best regards,

Tamas


2015-06-04 16:35 GMT+02:00 Ari Jolma ari.jo...@gmail.com:

 Hi,

 I've been trying to find a way to make the common SWIG interface files
 less concerned about languages and the whole system more flexible and
 understandable (which I see a prerequisite for further developments).

 My conclusion seems to be now that it is probably better to make the main
 files, what are now gdal.i, ogr.i etc., language specific and only the
 class files, now ColorTable.i, MajorObject.i, etc., and some other files
 (typedefs.i etc.) common. That way each language could compose the module
 as they like. For example in Perl I would like to get rid of Const, and a
 language could put all classes into one module (gdal) etc.

 This would at least require extracting remaining common material in gdal.i
 and ogr.i into new files.

 I'll test this in my github fork - which I've mentioned a couple of times
 already. But it will probably take some time due to summer etc.

 Any comments on this? This is again just internal reorganization and does
 not affect the APIs.

 Ari

 ___
 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] CSharp bindings question

[Tamas Szekeres]

Hi Ari,

Which SWIG version have you been testing with?

Converting IntPtr to string doesn't seem to be a good solution. We should
do something like what we do for ReadRaster which also use
AddrOfPinnedObject().
I'm trying to reproduce this.

Best regards,

Tamas


2015-05-29 9:11 GMT+02:00 Ari Jolma ari.jo...@gmail.com:

  In my fork I've now added mono-mcs into the travis test machine and make
 test to CSharp. The build  tests all work.

 https://travis-ci.org/OSGeo/gdal/builds/6445

 However, one fix I did for the CSharp bindings is most probably wrong
 (convert return value of handle.AddrOfPinnedObject() to char *)


 https://github.com/ajolma/gdal/commit/6509ef06d6f89d99c446300e4f4a63b65613911e

 Tamas, do you have an idea for this?

 There are a lot of #if ... #endif's in for example ogr.i to limit
 %feature(kwargs), this is due to a swig bug, which is fixed in 3.03 so we
 need to leave them in for now.

 https://github.com/swig/swig/issues/242

 There's a lot still to do to cleanup the common interface files but how do
 you feel, is there a chance that this is accepted into the trunk (and 2.1)?
 I'd also love to have a policy for developing the bindings and working test
 codes for all maintained languages. A rule could be that the use of #if ...
 #endif in common files needs a good justification and commits, which do not
 cause test codes to fail are ok per se.

 Best,

 Ari

 On 26.05.2015 13:53, Tamas Szekeres wrote:

 Is that a requirement that the bindings should work well with all SWIG
 versions or that the generated wrappers should work just fine?

  Formerly I have been thinking that we should support all versions, but
 it took large amount of extra efforts to work around all incompatible
 changes what SWIG introduces all the time even with the minor releases.
 Regarding to SWIG C# the earlier versions produced definitely wrong code
 and I had implement quite some generic stuff in the bindings (for example
 to work around the early garbage collection issues). I see some
 enhancements in the recent versions in this regard, but I'm not sure if I
 can completely remove these additions to get a stable and consistent build.

  Tamas



 2015-05-26 11:09 GMT+02:00 Ari Jolma ari.jo...@gmail.com:

 26.05.2015, 11:38, Even Rouault kirjoitti:

 Le mardi 26 mai 2015 10:13:49, Tamas Szekeres a écrit :

 Hi Ari,

 I haven't tried to compile that with mono for quite a long time. I'll
 give
 it a try.

 However we did not follow the latest changes in the SWIG implementation
 with the bindings, so I'd try with an earlier version (ie. 1.3.39) to
 generate the wrappers.

 I can confirm that I can compile the CSharp bindings on Linux with SWIG
 1.3.40
 (and run the tests), but I get the same error as Ari with SWIG 2.0.X

 As far as I know, Java and Python bindings build and run equaly well
 with SWIG
 1.3.40 or 2.0.X (although there's a Unix makefile hack to have Python 3.2
 compat, conditionnaly applied with SWIG 1.3.40, that is no longer needed
 with
 SWIG 2.0.4 or later)


  Swig 1.3.39 seems questionable. Just look at the download amounts at
 sourceforge. 1.3.39 one download and 1.3.40 148 downloads per week.

 However, 1.3.39 does *not* put the PVINVOKE() method twice into the
 PVINVOKE.cs file.


  May be we should consider including the generated
 wrappers in gdal instead of let the users to use different versions with
 different results.

 It would be good if we could have a common SWIG version that works for
 all the
 bindings. So currently it seems to be 1.3.40 ?

 Regarding putting the generated wrappers in SVN, that's already what we
 do for
 Python. We could also just include the generated wrappers in the
 tarballs.


  IMO users = people who use ready-made packages. Developers and
 packagers should be intelligent enough to use development tools. I don't
 like the idea of having generated files in source repositories. I'm also of
 the opinion that there should be a really good reason to use an old version
 of a common tool. And at least in my Linux (Mint, Maya - hmm, that seems
 already pretty old, I should upgrade) swig 2.0.11 is the current. But
 that's just me I guess.

 Ari


 Even





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

Re: [gdal-dev] CSharp bindings question

[Tamas Szekeres]

Hi Ari,

I haven't tried to compile that with mono for quite a long time. I'll give
it a try.

However we did not follow the latest changes in the SWIG implementation
with the bindings, so I'd try with an earlier version (ie. 1.3.39) to
generate the wrappers. May be we should consider including the generated
wrappers in gdal instead of let the users to use different versions with
different results.

The warning message should just be ignored at this stage.

Best regards,

Tamas



2015-05-26 9:43 GMT+02:00 Ari Jolma ari.jo...@gmail.com:

 Tamas,

 I'm working on a cleanup of the bindings, trying to reduce the number of
 language specifics in the common interface files.

 I can test Python, Java, and Perl bindings well in my Linux machine but
 can so far only generate and compile the CSharp wrappers. However, it seems
 maybe possible with Mono. I installed mcs but I'm now stuck with
 definitions with type

 static OgrPINVOKE() {
 }

 appearing twice in OgrPINVOKE.cs and similar files. It seems that this is
 not because of my changes so far - they appear also on trunk version. The
 error message is

 osr/OsrPINVOKE.cs(192,10): error CS0111: A member
 `OSGeo.OSR.OsrPINVOKE.OsrPINVOKE()' is already defined. Rename this member
 or use different parameter types

 Do you have any idea what's going on and if it is even possible to compile
 the CSharp bindings with Mono?

 Bindings generation and compilation of the wrapper code is ok, the error
 comes with command

 mcs /debug:full /target:library /out:osr_csharp.dll osr/*.cs
 AssemblyInfo.cs

 which is followed by

 AssemblyInfo.cs(88,12): warning CS1699: Use compiler option `keyfile' or
 appropriate project settings instead of `AssemblyKeyFile' attribute

 before the error (above).

 Regards,

 Ari

 ___
 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] CSharp bindings question

[Tamas Szekeres]

Is that a requirement that the bindings should work well with all SWIG
versions or that the generated wrappers should work just fine?

Formerly I have been thinking that we should support all versions, but it
took large amount of extra efforts to work around all incompatible changes
what SWIG introduces all the time even with the minor releases. Regarding
to SWIG C# the earlier versions produced definitely wrong code and I had
implement quite some generic stuff in the bindings (for example to work
around the early garbage collection issues). I see some enhancements in the
recent versions in this regard, but I'm not sure if I can completely remove
these additions to get a stable and consistent build.

Tamas



2015-05-26 11:09 GMT+02:00 Ari Jolma ari.jo...@gmail.com:

 26.05.2015, 11:38, Even Rouault kirjoitti:

 Le mardi 26 mai 2015 10:13:49, Tamas Szekeres a écrit :

 Hi Ari,

 I haven't tried to compile that with mono for quite a long time. I'll
 give
 it a try.

 However we did not follow the latest changes in the SWIG implementation
 with the bindings, so I'd try with an earlier version (ie. 1.3.39) to
 generate the wrappers.

 I can confirm that I can compile the CSharp bindings on Linux with SWIG
 1.3.40
 (and run the tests), but I get the same error as Ari with SWIG 2.0.X

 As far as I know, Java and Python bindings build and run equaly well with
 SWIG
 1.3.40 or 2.0.X (although there's a Unix makefile hack to have Python 3.2
 compat, conditionnaly applied with SWIG 1.3.40, that is no longer needed
 with
 SWIG 2.0.4 or later)


 Swig 1.3.39 seems questionable. Just look at the download amounts at
 sourceforge. 1.3.39 one download and 1.3.40 148 downloads per week.

 However, 1.3.39 does *not* put the PVINVOKE() method twice into the
 PVINVOKE.cs file.


  May be we should consider including the generated
 wrappers in gdal instead of let the users to use different versions with
 different results.

 It would be good if we could have a common SWIG version that works for
 all the
 bindings. So currently it seems to be 1.3.40 ?

 Regarding putting the generated wrappers in SVN, that's already what we
 do for
 Python. We could also just include the generated wrappers in the tarballs.


 IMO users = people who use ready-made packages. Developers and packagers
 should be intelligent enough to use development tools. I don't like the
 idea of having generated files in source repositories. I'm also of the
 opinion that there should be a really good reason to use an old version of
 a common tool. And at least in my Linux (Mint, Maya - hmm, that seems
 already pretty old, I should upgrade) swig 2.0.11 is the current. But
 that's just me I guess.

 Ari


 Even



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

Re: [gdal-dev] GDAL NuGet Package

[Tamas Szekeres]

As far as I remember the current packages have been produced by: Felix
Obermaier o...@ivv-aachen.de based on the gisinternals packages.

It is interesting that 2.5+ provides better native code support. I'd be
interested in looking into that but I have no spare time in short term.

If you with to get involved in the NuGet package creation, I'd help in
providing all details about the gisinternals packaging details and the
build process.


Best regards,

Tamas



2015-04-14 13:45 GMT+02:00 drp33t peet.whitta...@gmail.com:

 Certainly keen to help out! Disclaimer: I'm fairly familiar with NuGet, but
 only as a consumer, never as a package creator / contributor, so let me
 know
 if I'm way off the mark with anything ;)

 How were the existing packages created? Looking at the
 gisinternals/buildsystem on GitHub, I assume that there are no VS .proj
 files to auto-generate the package from?

 The good news is that there seems to be much better support for native code
 in NuGet now (from v2.5). I don't know if this was already used or if
 something else like CoApp was used?

 Regards,
 Peet Whittaker



 --
 View this message in context:
 http://osgeo-org.1560.x6.nabble.com/gdal-dev-GDAL-NuGet-Package-tp5201018p5201267.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] GDAL NuGet Package

[Tamas Szekeres]

I've planned to provide nuget packages from the binaries provided at
http://www.gisinternals.com/ long ago, but I had no time to include this
support so far.

The corresponding ticket can be found here:

https://github.com/gisinternals/buildsystem/issues/9

The key features of the packaging should be:

1. Support multiple Visual Studio versions.
2. Support the selection of x86/x64.
3. Support release versions as well as and daily built updates.
4. Packaging should fit into the automated build process (should be done
using command line tools).


Any help would be appreciated have this setup realized.

Best regards,

Tamas



2015-04-13 10:54 GMT+02:00 drp33t peet.whitta...@gmail.com:

 Hi,

 I am wondering there are any plans to update the version of the GDAL
 package
 in NuGet? Currently the stable release is at version 1.9 (released
 2012-12-20) and there is also a pre-release alpha for 1.10 (last updated
 2014-01-08).

 It would be very beneficial for my work if either 1.10 or 1.11 were
 available through NuGet. I am willing to help update / maintain the NuGet
 packages if needed.

 Regards,
 Peet Whittaker



 --
 View this message in context:
 http://osgeo-org.1560.x6.nabble.com/gdal-dev-GDAL-NuGet-Package-tp5201018.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: Approve GDAL/OGR 1.11.2RC2 for release

[Tamas Szekeres]

+1

Tamas



2015-02-12 18:55 GMT+01:00 Even Rouault even.roua...@spatialys.com:

 Hi,

 No issue has been reported on RC2, so I invite PSC members to vote on this
 motion after doing your own testing and validation.
 Input from everyone else who can test it is also very welcome.

 ---

 Motion: The GDAL/OGR 1.11.2RC2 package is promoted as the
 final GDAL/OGR 1.11.2 release.

 +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: Adopt RFC 52 - Strict OGR SQL quoting

[Tamas Szekeres]

+1

Tamas

2015-01-30 17:41 GMT+01:00 Even Rouault even.roua...@spatialys.com:

 Hi,

 Since the call for discussion, I've updated the RFC to point to the
 proposed
 refreshed implementation against current trunk.

 So:

 Motion : I move to adopt RFC 52 - Strict OGR SQL quoting

 http://trac.osgeo.org/gdal/wiki/rfc52_strict_sql_quoting

 Starting with my +1

 Best regards,

 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] Python3 continuous testing

[Tamas Szekeres]

Hi Even,

I'm always confused about the GDAL-python bindings what is the best
approach to use. The SWIG generated output is also included in the
bindings, but as far as I remember it wasn't always up to date. Also the
windows makefile will generate the bindings by default and there's no
option to bypass this step as far as I remember.

On the other hand, I'm not quite sure which one is the suggested SWIG
version to generate the bindings, I also remember the cases when the recent
version wasn't sufficient and we had to use an earlier SWIG version to
compile. Not sure how it depends on the Python version either.

I think we should either remove the SWIG generated output from the
repository or modify the makefiles not to generate the output every time.

Best regards,

Tamas



2015-01-28 9:59 GMT+01:00 Even Rouault even.roua...@spatialys.com:

 Le mardi 27 janvier 2015 23:18:45, Tamas Szekeres a écrit :
  Hi Even,
 
  I get this output from a Python 3.4 build (VS2012):
 
 
  E:\builds\Python34\python.exe setup.py build
  running build
  running build_py
  creating build
  creating build\lib.win32-3.4
  copying gdal.py - build\lib.win32-3.4
  copying ogr.py - build\lib.win32-3.4
  copying osr.py - build\lib.win32-3.4
  copying gdalconst.py - build\lib.win32-3.4
  copying gdalnumeric.py - build\lib.win32-3.4
  creating build\lib.win32-3.4\osgeo
  copying osgeo\gdal.py - build\lib.win32-3.4\osgeo
  copying osgeo\gdalconst.py - build\lib.win32-3.4\osgeo
  copying osgeo\gdalnumeric.py - build\lib.win32-3.4\osgeo
  copying osgeo\gdal_array.py - build\lib.win32-3.4\osgeo
  copying osgeo\ogr.py - build\lib.win32-3.4\osgeo
  copying osgeo\osr.py - build\lib.win32-3.4\osgeo
  copying osgeo\__init__.py - build\lib.win32-3.4\osgeo
  Fixing build\lib.win32-3.4\gdal.py build\lib.win32-3.4\ogr.py
  build\lib.win32-3.4\osr.py build\lib.win32-3.4\gdalconst.py
  build\lib.win32-3.4\gdalnumeric.py build\lib.win32-3.4\osgeo\gdal.py
  build\lib.win32-3.4\osgeo\gdalconst.py
  build\lib.win32-3.4\osgeo\gdalnumeric.py
  build\lib.win32-3.4\osgeo\gdal_array.py build\lib.win32-3.4\osgeo\ogr.py
  build\lib.win32-3.4\osgeo\osr.py build\lib.win32-3.4\osgeo\__init__.py
  Skipping implicit fixer: ws_comma
  Fixing build\lib.win32-3.4\gdal.py build\lib.win32-3.4\ogr.py
  build\lib.win32-3.4\osr.py build\lib.win32-3.4\gdalconst.py
  build\lib.win32-3.4\gdalnumeric.py build\lib.win32-3.4\osgeo\gdal.py
  build\lib.win32-3.4\osgeo\gdalconst.py
  build\lib.win32-3.4\osgeo\gdalnumeric.py
  build\lib.win32-3.4\osgeo\gdal_array.py build\lib.win32-3.4\osgeo\ogr.py
  build\lib.win32-3.4\osgeo\osr.py build\lib.win32-3.4\osgeo\__init__.py
  Skipping implicit fixer: ws_comma
  running build_ext
  building 'osgeo._gdal' extension
  creating build\temp.win32-3.4
  creating build\temp.win32-3.4\Release
  creating build\temp.win32-3.4\Release\extensions
  C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\BIN\cl.exe /c
  /nologo /Ox /MD /W3 /GS- /DNDEBUG -I../../port -I../../gcore -I../../alg
  -I../../ogr/ -IE:\builds\Python34\include -IE:\builds\Python34\include
  -IE:\builds\Python34\lib\site-packages\numpy\core\include
  /Tpextensions/gdal_wrap.cpp
  /Fobuild\temp.win32-3.4\Release\extensions/gdal_wrap.obj
  gdal_wrap.cpp
  extensions/gdal_wrap.cpp(2451) : error C3861: 'PyCObject_Import':
  identifier not found
  extensions/gdal_wrap.cpp(2521) : error C3861: 'PyCObject_FromVoidPtr':
  identifier not found
  extensions/gdal_wrap.cpp(2544) : error C3861: 'PyCObject_AsVoidPtr':
  identifier not found
  extensions/gdal_wrap.cpp(2549) : error C3861: 'PyCObject_FromVoidPtr':
  identifier not found

 -- This is SWIG generated code, so perhaps you need to update to a newer
 SWIG
 that supports Python 3.4 ?

 --
 Spatialys - Geospatial professional services
 http://www.spatialys.com

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

Re: [gdal-dev] Motion: Adopt RFC 31 - OGR 64bit Integer Fields and FIDs

[Tamas Szekeres]

+1

Tamas

2015-01-28 13:23 GMT+01:00 Even Rouault even.roua...@spatialys.com:

 Hi,

 I think that the points raised in the discussion have been addressed.

 Since the call for discussion, I've updated the RFC to reflect the latest
 changes :
 - GetFID64()/GetFeatureCount64() removed and replaced by
 GetFID()/GetFeatureCount() whose return type is changed to GIntBig
 - MITAB driver updated with change for seamless table FIDs

 So:

 Motion : I move to adopt RFC 31 - OGR 64bit Integer Fields and FIDs

 http://trac.osgeo.org/gdal/wiki/rfc31_ogr_64

 Starting with my +1

 Best regards,

 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