date:20151123

Re: [gdal-dev] Ingesting ESRI geometry into PostGIS

2015-11-23 Thread Paul Ramsey

This is a non-sequitur "PostgreSQL/PostGIS that has the default 
geometry_storage parameter set to st_geometry”. The ST_Geometry type is an ESRI 
thing, and you need to have ESRI dll’s installed in your PostgreSQL/ESRI server 
in order to create such a column. That’s Problem #1. 

Problem #2 is that GDAL doesn’t support writing to a PostgreSQL/ESRI database, 
so you’ll have to write a suitable driver for that.

ATB,

P.

On November 23, 2015 at 10:34:28 AM, David Vick (dv...@boundlessgeo.com) wrote:

All,

I'm trying to use ogr2ogr to ingest FileGDB's into PostgreSQL/PostGIS that has 
the default geometry_storage parameter set to st_geometry.  When running 
ogr2ogr with DEBUG on I see a message PG: Field shape is of unknown format type 
st_multipolygon

[gdal-dev] Ingesting ESRI geometry into PostGIS

2015-11-23 Thread David Vick

All,

I'm trying to use ogr2ogr to ingest FileGDB's into PostgreSQL/PostGIS that
has the default geometry_storage parameter set to st_geometry.  When
running ogr2ogr with DEBUG on I see a message PG: Field shape is of unknown
format type st_multipolygon

Re: [gdal-dev] RFC 48: Geographical networks support

2015-11-23 Thread Dmitry Baryshnikov


Hi Paul,

The RFS48 implemented, but only in trunk. The plan for release was on 
GDAL 2.1.


Yes, you can create shortest path between 2 points using a shapefile of 
roads, but the graph needed to be created. The autocreate method 
developed mostly for points (valves) and lines (tubes) so it may be 
unusable for you case in current implementation.

The details is here:
https://github.com/OSGeo/gdal/blob/trunk/gdal/gnm/gnm_tut.dox
https://github.com/OSGeo/gdal/blob/trunk/gdal/gnm/gnm_arch.dox
https://github.com/OSGeo/gdal/blob/trunk/gdal/apps/gnm_utilities.dox

Also, I would like to note, what GNMGenericNetowrk is not optimized now 
for big datasets (all graph stored in memory).


Best regards,
Dmitry

23.11.2015 10:50, Paul Meems пишет:

Hi List,

I'm looking at this RFC. Is it already implemented in GDAL v2?
And can we use it to create the shortest path between 2 points using a 
shapefile of roads (linestring)


Thanks,

Paul

*Paul Meems *
Release manager, configuration manager
and forum moderator of MapWindow GIS.
www.mapwindow.org 

Owner of MapWindow.nl - Support for
Dutch speaking users.
www.mapwindow.nl 

*
*

*We've started with the development of MapWindow v5. Read more. 


*



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


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

[gdal-dev] Two versions of gdal

2015-11-23 Thread Gane R

I have a requirement of two version of gdal one with filegeodb (gdal 2.0.1)
and other without filegeodb (gdal 2.0.1) on linux, any references how this
can make co exist ?

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

Re: [gdal-dev] unable to open DGN

2015-11-23 Thread Even Rouault

Le lundi 23 novembre 2015 16:48:48, Andre Vautour a écrit :
> Right, thanks, I wasn't thinking of that when I wrote my reply.
> 
> Guess it makes sense for a closed format such as DWG. Might not make as
> much sense to use it for DGN which is more open

DGN v8: open ? If you have pointers to a spec, I think that would be much 
appreciated by a lot of people...

> and does not need to be
> reverse engineered.
> André
> 
> On 2015-11-23 11:41, Ivan Lucena wrote:
> > Just a comment on that: In order to build the DWG driver, you or your
> > company, need to be part of some kind of alliance to be able to download
> > a full version of the Teigha SDK. AFAIK
> > 
> > 
> > From: gdal-dev  on behalf of Andre
> > Vautour  Sent: Monday, November 23, 2015 9:58
> > AM
> > To: Brad Hards
> > Cc: gdal-dev@lists.osgeo.org
> > Subject: Re: [gdal-dev] unable to open DGN
> > 
> > On 2015-11-20 17:40, Brad Hards wrote:
> >> On Fri, 20 Nov 2015 02:20:55 PM Martin Landa wrote:
> >>> I am trying to open sample DGN file, but it fails. I guess that the
> >>> reason is unsupported version (man pages says: Microstation DGN files
> >>> from Microstation versions predating version 8.0 are supported for
> >>> reading.)
> >> 
> >> As I understand it, version 8 is completely different.
> >> 
> >>> Is there any possibility how to read this file using GDAL library?
> >> 
> >> AFAICT, not unless you figure out version 8 format and implement it, or
> >> pay someone to do that work for you.
> > 
> > I just want to add that Teigha, which can currently be used to open DWG
> > in GDAL, does support DGN version 8. So, if someone wants to add that
> > support, I'd suggest looking at the DWG driver.
> > 
> > The DWG driver has:
> > class OGRDWGServices : public ExSystemServices, public ExHostAppServices
> > 
> > You'd need to have something like:
> > class OGRDGNServices : public OdRxSystemServices, public
> > OdDgHostAppServices
> > 
> > I would not be surprised if considerable chunks of the DWG driver could
> > be generalized to work for both DWG and DGN,
> > André
> > 
> >>Is it possibly to get the originator to
> >> 
> >> provide it in some other format (e.g. DXF, noting that will lose the
> >> georeferencing)?
> >> 
> >> Brad
> >> ___
> >> gdal-dev mailing list
> >> gdal-dev@lists.osgeo.org
> >> http://lists.osgeo.org/mailman/listinfo/gdal-dev
> > 
> > ___
> > gdal-dev mailing list
> > gdal-dev@lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/gdal-dev
> 
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
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] unable to open DGN

2015-11-23 Thread Andre Vautour



On 2015-11-23 12:00, Even Rouault wrote:

Le lundi 23 novembre 2015 16:48:48, Andre Vautour a écrit :

Right, thanks, I wasn't thinking of that when I wrote my reply.

Guess it makes sense for a closed format such as DWG. Might not make as
much sense to use it for DGN which is more open

DGN v8: open ? If you have pointers to a spec, I think that would be much
appreciated by a lot of people...
I apologize, clearly I am not thinking straight today. What I meant to 
say is that Ivan made me realize why the DGN driver was probably not 
implemented by using DGNDirect or Teigha: there was some sort of spec 
available: http://dgnlib.maptools.org/dgn.html.


So, I agree that if using an Open Design library to support such a 
format can be avoided, it would make sense to do so, given their 
licensing. Like I said, I wasn't thinking of that when I first replied.


Kind regards,
André


and does not need to be
reverse engineered.
André

On 2015-11-23 11:41, Ivan Lucena wrote:

Just a comment on that: In order to build the DWG driver, you or your
company, need to be part of some kind of alliance to be able to download
a full version of the Teigha SDK. AFAIK


From: gdal-dev  on behalf of Andre
Vautour  Sent: Monday, November 23, 2015 9:58
AM
To: Brad Hards
Cc: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] unable to open DGN

On 2015-11-20 17:40, Brad Hards wrote:

On Fri, 20 Nov 2015 02:20:55 PM Martin Landa wrote:

I am trying to open sample DGN file, but it fails. I guess that the
reason is unsupported version (man pages says: Microstation DGN files
from Microstation versions predating version 8.0 are supported for
reading.)

As I understand it, version 8 is completely different.


Is there any possibility how to read this file using GDAL library?

AFAICT, not unless you figure out version 8 format and implement it, or
pay someone to do that work for you.

I just want to add that Teigha, which can currently be used to open DWG
in GDAL, does support DGN version 8. So, if someone wants to add that
support, I'd suggest looking at the DWG driver.

The DWG driver has:
class OGRDWGServices : public ExSystemServices, public ExHostAppServices

You'd need to have something like:
class OGRDGNServices : public OdRxSystemServices, public
OdDgHostAppServices

I would not be surprised if considerable chunks of the DWG driver could
be generalized to work for both DWG and DGN,
André


Is it possibly to get the originator to

provide it in some other format (e.g. DXF, noting that will lose the
georeferencing)?

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

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

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

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

Re: [gdal-dev] Two versions of gdal

2015-11-23 Thread Gane R

Thanks for your reply, I have a requirement that I should have two GDALs. I
have also an issue, I have build gdal 2.0.1 with proj4 as static, it does
not process the geometry inside from filegeodb. any thoughts will be
appreciated. I have the GDAL_DATA environ set, and pro4 share lib also
exist on the machine and ldconfig is also called to update the shared
library.

Thanks
Gane

On Mon, Nov 23, 2015 at 7:49 PM, Ivan Lucena 
wrote:

> You don't need to build two gdal versions.
>
>
> You can build GDAL (libgal.so) without the driver and then you build the
> driver as a plugin (ogr_FileGDB.so).
>
>
> ./configure -without-fgdb
>
> make
>
>
> ./configure -with-fgdb
>
> make
>
>
> You can choose to use the drive, or not, by managing the GDAL_DRIVER_PATH
> environment variable.
>
>
> The advantage is that libgdal.so is not going to depend on FileGDB SDK.
>
>
> --
> *From:* gdal-dev  on behalf of Gane R <
> gane.p...@gmail.com>
> *Sent:* Monday, November 23, 2015 8:24 AM
> *To:* Even Rouault; gdal-dev@lists.osgeo.org
> *Subject:* [gdal-dev] Two versions of gdal
>
> I have a requirement of two version of gdal one with filegeodb (gdal
> 2.0.1) and other without filegeodb (gdal 2.0.1) on linux, any references
> how this can make co exist ?
>
> thanks
> Gane
>
>
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] unable to open DGN

2015-11-23 Thread Andre Vautour


Right, thanks, I wasn't thinking of that when I wrote my reply.

Guess it makes sense for a closed format such as DWG. Might not make as 
much sense to use it for DGN which is more open and does not need to be 
reverse engineered.

André

On 2015-11-23 11:41, Ivan Lucena wrote:

Just a comment on that: In order to build the DWG driver, you or your company, 
need to be part of some kind of alliance to be able to download a full version 
of the Teigha SDK. AFAIK


From: gdal-dev  on behalf of Andre Vautour 

Sent: Monday, November 23, 2015 9:58 AM
To: Brad Hards
Cc: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] unable to open DGN

On 2015-11-20 17:40, Brad Hards wrote:

On Fri, 20 Nov 2015 02:20:55 PM Martin Landa wrote:

I am trying to open sample DGN file, but it fails. I guess that the
reason is unsupported version (man pages says: Microstation DGN files
from Microstation versions predating version 8.0 are supported for
reading.)

As I understand it, version 8 is completely different.


Is there any possibility how to read this file using GDAL library?

AFAICT, not unless you figure out version 8 format and implement it, or pay
someone to do that work for you.

I just want to add that Teigha, which can currently be used to open DWG
in GDAL, does support DGN version 8. So, if someone wants to add that
support, I'd suggest looking at the DWG driver.

The DWG driver has:
class OGRDWGServices : public ExSystemServices, public ExHostAppServices

You'd need to have something like:
class OGRDGNServices : public OdRxSystemServices, public OdDgHostAppServices

I would not be surprised if considerable chunks of the DWG driver could
be generalized to work for both DWG and DGN,
André


   Is it possibly to get the originator to
provide it in some other format (e.g. DXF, noting that will lose the
georeferencing)?

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

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

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

Re: [gdal-dev] unable to open DGN

2015-11-23 Thread A Huarte

Hi, sorry for intruding, this help describes the specification of --v95/v7-- 
versions.
The --v8-- spec is different, OpenDGN only supports read v95/v7 files, and 
read/write v8 files.
Alvaro
  De: Andre Vautour 
 Para: Even Rouault  
CC: gdal-dev@lists.osgeo.org
 Enviado: Lunes 23 de noviembre de 2015 17:23
 Asunto: Re: [gdal-dev] unable to open DGN
   

On 2015-11-23 12:00, Even Rouault wrote:
> Le lundi 23 novembre 2015 16:48:48, Andre Vautour a écrit :
>> Right, thanks, I wasn't thinking of that when I wrote my reply.
>>
>> Guess it makes sense for a closed format such as DWG. Might not make as
>> much sense to use it for DGN which is more open
> DGN v8: open ? If you have pointers to a spec, I think that would be much
> appreciated by a lot of people...
I apologize, clearly I am not thinking straight today. What I meant to 
say is that Ivan made me realize why the DGN driver was probably not 
implemented by using DGNDirect or Teigha: there was some sort of spec 
available: http://dgnlib.maptools.org/dgn.html.

So, I agree that if using an Open Design library to support such a 
format can be avoided, it would make sense to do so, given their 
licensing. Like I said, I wasn't thinking of that when I first replied.

Kind regards,
André



>> and does not need to be
>> reverse engineered.
>> André
>>
>> On 2015-11-23 11:41, Ivan Lucena wrote:
>>> Just a comment on that: In order to build the DWG driver, you or your
>>> company, need to be part of some kind of alliance to be able to download
>>> a full version of the Teigha SDK. AFAIK
>>>
>>> 
>>> From: gdal-dev  on behalf of Andre
>>> Vautour  Sent: Monday, November 23, 2015 9:58
>>> AM
>>> To: Brad Hards
>>> Cc: gdal-dev@lists.osgeo.org
>>> Subject: Re: [gdal-dev] unable to open DGN
>>>
>>> On 2015-11-20 17:40, Brad Hards wrote:
 On Fri, 20 Nov 2015 02:20:55 PM Martin Landa wrote:
> I am trying to open sample DGN file, but it fails. I guess that the
> reason is unsupported version (man pages says: Microstation DGN files
> from Microstation versions predating version 8.0 are supported for
> reading.)
 As I understand it, version 8 is completely different.

> Is there any possibility how to read this file using GDAL library?
 AFAICT, not unless you figure out version 8 format and implement it, or
 pay someone to do that work for you.
>>> I just want to add that Teigha, which can currently be used to open DWG
>>> in GDAL, does support DGN version 8. So, if someone wants to add that
>>> support, I'd suggest looking at the DWG driver.
>>>
>>> The DWG driver has:
>>> class OGRDWGServices : public ExSystemServices, public ExHostAppServices
>>>
>>> You'd need to have something like:
>>> class OGRDGNServices : public OdRxSystemServices, public
>>> OdDgHostAppServices
>>>
>>> I would not be surprised if considerable chunks of the DWG driver could
>>> be generalized to work for both DWG and DGN,
>>> André
>>>
    Is it possibly to get the originator to

 provide it in some other format (e.g. DXF, noting that will lose the
 georeferencing)?

 Brad
 ___
 gdal-dev mailing list
 gdal-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/gdal-dev
>>> ___
>>> gdal-dev mailing list
>>> gdal-dev@lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>> ___
>> gdal-dev mailing list
>> gdal-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev 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] Ingesting ESRI geometry into PostGIS

2015-11-23 Thread David Vick

Paul,

Thanks for the response.  We are running ArcSDE on top of the PostgreSQL
server hence the first part of the question.  As part of our process we are
using ArcObjects to extract the schema of the FileGDB and write the schema
to PostgreSQL and then are attempting to use gdal/ogr2ogr to move the data
as this is much faster than ESRI's processes, but this has failed and now
we know why.  Your second point is quite clear and something that my client
will have to look at in the future.

David Vick

Professional Services Engineer | Boundless 
dv...@boundlessgeo.com
mobile: 1-636-698-3174

On Mon, Nov 23, 2015 at 12:41 PM, Paul Ramsey 
wrote:

> This is a non-sequitur "PostgreSQL/PostGIS that has the default
> geometry_storage parameter set to st_geometry”. The ST_Geometry type is an
> ESRI thing, and you need to have ESRI dll’s installed in your
> PostgreSQL/ESRI server in order to create such a column. That’s Problem #1.
>
> Problem #2 is that GDAL doesn’t support writing to a PostgreSQL/ESRI
> database, so you’ll have to write a suitable driver for that.
>
> ATB,
>
> P.
>
> On November 23, 2015 at 10:34:28 AM, David Vick (dv...@boundlessgeo.com)
> wrote:
>
> All,
>
> I'm trying to use ogr2ogr to ingest FileGDB's into PostgreSQL/PostGIS that
> has the default geometry_storage parameter set to st_geometry.  When
> running ogr2ogr with DEBUG on I see a message PG: Field shape is of unknown
> format type st_multipolygon

[gdal-dev] Geometry not displayed with Filegeodb on GDAL 2.0.1

2015-11-23 Thread Gane R

Hi all,

I tried to build *GDAL 2.0.1* with *filegeodb* support with *proj4* as
static lib on *Linux*. I am able to use the API to get the field data from
Filegeodb but I am *not able to get the geometry*.  I have configured as

./configure --with-fgdb=/fgdblib --with-static-proj4=/usr/local/
--with-xml2=no --with-sqlite3=no --with-curl=no --with-expat=no

I am wondering what went wrong. But ogrinfo shows the values of the same
filegeodb file.

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

Re: [gdal-dev] unable to open DGN

2015-11-23 Thread Ivan Lucena

Just a comment on that: In order to build the DWG driver, you or your company, 
need to be part of some kind of alliance to be able to download a full version 
of the Teigha SDK. AFAIK


From: gdal-dev  on behalf of Andre Vautour 

Sent: Monday, November 23, 2015 9:58 AM
To: Brad Hards
Cc: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] unable to open DGN

On 2015-11-20 17:40, Brad Hards wrote:
> On Fri, 20 Nov 2015 02:20:55 PM Martin Landa wrote:
>> I am trying to open sample DGN file, but it fails. I guess that the
>> reason is unsupported version (man pages says: Microstation DGN files
>> from Microstation versions predating version 8.0 are supported for
>> reading.)
> As I understand it, version 8 is completely different.
>
>> Is there any possibility how to read this file using GDAL library?
> AFAICT, not unless you figure out version 8 format and implement it, or pay
> someone to do that work for you.
I just want to add that Teigha, which can currently be used to open DWG
in GDAL, does support DGN version 8. So, if someone wants to add that
support, I'd suggest looking at the DWG driver.

The DWG driver has:
class OGRDWGServices : public ExSystemServices, public ExHostAppServices

You'd need to have something like:
class OGRDGNServices : public OdRxSystemServices, public OdDgHostAppServices

I would not be surprised if considerable chunks of the DWG driver could
be generalized to work for both DWG and DGN,
André

>   Is it possibly to get the originator to
> provide it in some other format (e.g. DXF, noting that will lose the
> georeferencing)?
>
> Brad
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] WMS MINRESOLUTION can lead to overflow of raster dimensions

2015-11-23 Thread Timothy Astle

I'm trying to open a WMS dataset using the minimally documented 
MINRESOLUTION option. (http://www.gdal.org/frmt_wms.html)


When providing a way-too-fine resolution, I manage to create a raster 
that exceeds GDALs 32-bit integer based dimensions.  Below shows what 
I'm seeing.  You can see that one of the dimensions has overflowed.


gdal_translate.exe -of PNG 
"http://nowcoast.noaa.gov:80/wms/com.esri.wms.Esrimap/obs?SERVICE=WMS=1.1.1=GetMap=RAS_RIDGE_NEXRAD=EPSG:4326=-180,-90,180,90=true=8.98315e-008; 
my.png


ERROR 1: Invalid dataset dimensions : -2147483648 x 2003751468
GDALOpen failed - 1
Invalid dataset dimensions : -2147483648 x 2003751468

I'm wondering if it'd make sense to handle the kind of input that would 
cause this problem to surface.  Looking at the calculations made in the 
wmsdriver, when a MINRESOLUTION is provided the following code is where 
the issue happens:


if (osMinResolution.size() != 0)
{
double dfMinResolution = CPLAtofM(osMinResolution);

while (nOverviewCount > 20)
{
nOverviewCount --;
dfMinResolution *= 2;
}

nXSize = (int) ((dfMaxX - dfMinX) / dfMinResolution + 0.5);
nYSize = (int) ((dfMaxY - dfMinY) / dfMinResolution + 0.5);
}

Would it make sense to do something as follows?  (Note:  I haven't tried 
this yet, I'm just soliciting early feedback so please bare with me )



if (osMinResolution.size() != 0)
{
double dfMinResolution = CPLAtofM(osMinResolution);

while (nOverviewCount > 20)
{
nOverviewCount --;
dfMinResolution *= 2;
}

// *** Changes here ***
// Determine a suitable resolution that doesn't overflow max int.
double dXSize = ((dfMaxX - dfMinX) / dfMinResolution + 0.5);
double dYSize = ((dfMaxY - dfMinY) / dfMinResolution + 0.5);

while (dXSize > INT_MAX || dYSize > INT_MAX)
{
nOverviewCount --;
dfMinResolution *= 2;

dXSize = ((dfMaxX - dfMinX) / dfMinResolution + 0.5);
dYSize = ((dfMaxY - dfMinY) / dfMinResolution + 0.5);
}

nXSize = (int) dXSize;
nYSize = (int) dYSize;
}

Any thoughts?


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

Re: [gdal-dev] WMS MINRESOLUTION can lead to overflow of raster dimensions

2015-11-23 Thread Even Rouault

Tim,

> Would it make sense to do something as follows?  (Note:  I haven't tried
> this yet, I'm just soliciting early feedback so please bare with me )
> 
> 
>  if (osMinResolution.size() != 0)
>  {
>  double dfMinResolution = CPLAtofM(osMinResolution);
> 
>  while (nOverviewCount > 20)
>  {
>  nOverviewCount --;
>  dfMinResolution *= 2;
>  }
> 
>  // *** Changes here ***
>  // Determine a suitable resolution that doesn't overflow max int.
>  double dXSize = ((dfMaxX - dfMinX) / dfMinResolution + 0.5);
>  double dYSize = ((dfMaxY - dfMinY) / dfMinResolution + 0.5);
> 
>  while (dXSize > INT_MAX || dYSize > INT_MAX)
>  {
>  nOverviewCount --;

I'm not sure we need to decrement the number of overviews in that loop.

>  dfMinResolution *= 2;
> 
>  dXSize = ((dfMaxX - dfMinX) / dfMinResolution + 0.5);
>  dYSize = ((dfMaxY - dfMinY) / dfMinResolution + 0.5);
>  }
> 
>  nXSize = (int) dXSize;
>  nYSize = (int) dYSize;
>  }
> 
> Any thoughts?

If that works, please open a ticket with the patch.

For extra bonus, I see that a few lines below a similar overflow could also 
occur :

"""
else
{
double dfRatio = (dfMaxX - dfMinX) / (dfMaxY - dfMinY);
if (dfRatio > 1)
{
nXSize = nTileSize;
nYSize = (int) (nXSize / dfRatio);
}
else
{
nYSize = nTileSize;
nXSize = (int) (nYSize * dfRatio);
}

if (nOverviewCount < 0 || nOverviewCount > 20)
nOverviewCount = 20;

nXSize = nXSize * (1 << nOverviewCount);
nYSize = nYSize * (1 << nOverviewCount);
}
"""

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

Re: [gdal-dev] Ingesting ESRI geometry into PostGIS

2015-11-23 Thread Stefan Keller

See also https://trac.osgeo.org/postgis/wiki/UsersWikiPostgisarcgis

:S

2015-11-23 20:01 GMT+01:00 David Vick :

> Paul,
>
> Thanks for the response.  We are running ArcSDE on top of the PostgreSQL
> server hence the first part of the question.  As part of our process we are
> using ArcObjects to extract the schema of the FileGDB and write the schema
> to PostgreSQL and then are attempting to use gdal/ogr2ogr to move the data
> as this is much faster than ESRI's processes, but this has failed and now
> we know why.  Your second point is quite clear and something that my client
> will have to look at in the future.
>
> David Vick
>
> Professional Services Engineer | Boundless 
> dv...@boundlessgeo.com
> mobile: 1-636-698-3174
>
>
> On Mon, Nov 23, 2015 at 12:41 PM, Paul Ramsey 
> wrote:
>
>> This is a non-sequitur "PostgreSQL/PostGIS that has the default
>> geometry_storage parameter set to st_geometry”. The ST_Geometry type is an
>> ESRI thing, and you need to have ESRI dll’s installed in your
>> PostgreSQL/ESRI server in order to create such a column. That’s Problem #1.
>>
>> Problem #2 is that GDAL doesn’t support writing to a PostgreSQL/ESRI
>> database, so you’ll have to write a suitable driver for that.
>>
>> ATB,
>>
>> P.
>>
>> On November 23, 2015 at 10:34:28 AM, David Vick (dv...@boundlessgeo.com)
>> wrote:
>>
>> All,
>>
>> I'm trying to use ogr2ogr to ingest FileGDB's into PostgreSQL/PostGIS
>> that has the default geometry_storage parameter set to st_geometry.  When
>> running ogr2ogr with DEBUG on I see a message PG: Field shape is of unknown
>> format type st_multipolygon

Re: [gdal-dev] Ingesting ESRI geometry into PostGIS

[gdal-dev] Ingesting ESRI geometry into PostGIS

Re: [gdal-dev] RFC 48: Geographical networks support

[gdal-dev] Two versions of gdal

Re: [gdal-dev] unable to open DGN

Re: [gdal-dev] unable to open DGN

Re: [gdal-dev] Two versions of gdal

Re: [gdal-dev] unable to open DGN

Re: [gdal-dev] unable to open DGN

Re: [gdal-dev] Ingesting ESRI geometry into PostGIS

[gdal-dev] Geometry not displayed with Filegeodb on GDAL 2.0.1

Re: [gdal-dev] unable to open DGN

[gdal-dev] WMS MINRESOLUTION can lead to overflow of raster dimensions

Re: [gdal-dev] WMS MINRESOLUTION can lead to overflow of raster dimensions

Re: [gdal-dev] Ingesting ESRI geometry into PostGIS

15 matches

Site Navigation

Mail list logo

Footer information