Re: [gdal-dev] XY Tolerance = 0 when creating layer in region settings with comma decimal separator

[Even Rouault]

Karen,

I've done some experiments on Linux, by forcing the locale of the 
process to a locale with comma as decimal separator and I can't 
reproduce an issue. What I see in the code is that we pass the tolerance 
as a string to the binary FileGDB SDK, but there's clearly at least 
validation from it of numeric values. Although I can see that passing 
XYTOLERANCE=1.23 or 1.230 results in different things in the XML, so it 
doesn't seem that it is rewritten. So I'm not sure what happens. It 
might behave differently on Windows, but hard to say what happens as we 
don't have the sources. Perhaps you have a way of programmatically 
changing the locale (or equivalent concept) in your code, at least 
temporarily, to force dot as decimal separator ?


Even

Le 02/09/2021 à 22:03, Karen M via gdal-dev a écrit :

Hi All,

I'm using the C# bindings in gdal version 
release-1900-x64-gdal-2-4-3-mapserver-7-4-2.  When the operating 
system region settings are set to regions that uses a comma as the 
decimal separator and I use datasource.CreateLayer() to create a new 
file geodatabase layer, the resulting feature class has XY Tolerance = 
0 when I use the layer in ArcGIS Pro.  When I use a region that uses 
decimal points, the XY Tolerance is non-zero (which is correct).


I've tried using the option "XYTOLERANCE=0.8983153" in 
CreateLayer(), but I still get XY Tolerance = 0.  This is causing some 
editing problems in ArcGIS Pro, and I need the software to work with 
various region settings, not just ones that use decimal points.  
Anyone have any suggestions how to fix this?


Thanks,

*Karen Meinstein*
Product Support
kbmeinst...@rothwellgroup.com  | 
303-261-8107 x 15


The Rothwell Group, L.P. 

RothwellGroup.com  | PaleoGIS.com 
 | BizRun.com 


___
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

[gdal-dev] XY Tolerance = 0 when creating layer in region settings with comma decimal separator

[Karen M via gdal-dev]

Hi All,

I'm using the C# bindings in gdal version
release-1900-x64-gdal-2-4-3-mapserver-7-4-2.  When the operating system
region settings are set to regions that uses a comma as the decimal
separator and I use datasource.CreateLayer() to create a new file
geodatabase layer, the resulting feature class has XY Tolerance = 0 when I
use the layer in ArcGIS Pro.  When I use a region that uses decimal points,
the XY Tolerance is non-zero (which is correct).

I've tried using the option "XYTOLERANCE=0.8983153" in
CreateLayer(), but I still get XY Tolerance = 0.  This is causing some
editing problems in ArcGIS Pro, and I need the software to work with
various region settings, not just ones that use decimal points.  Anyone
have any suggestions how to fix this?

Thanks,

*Karen Meinstein*
Product Support
kbmeinst...@rothwellgroup.com | 303-261-8107 x 15

[image: The Rothwell Group, L.P.]


RothwellGroup.com  | PaleoGIS.com
 | BizRun.com 
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] read ESRIJSON with ogr2ogr

[Hugh Kelley]

worked like a charm, thanks very much!

On Thu, Sep 2, 2021 at 2:13 PM Even Rouault 
wrote:

> Hugh,
>
> I've queued in https://github.com/OSGeo/gdal/pull/4418 a fix for that.
>
> But there's a simple workaround. Just remove the ESRIJSON: prefix in the
> connection string. In that instance, the driver will be automatically
> detected
>
> Even
> Le 02/09/2021 à 19:30, Hugh Kelley a écrit :
>
> Hi all,
>
> I'd like to load some data directly from an arcgis REST feature service
> using ogr2ogr.
>
> The command that follows collects exactly 5000 features, which i assume is
> the server limit mentioned in the ESRIJSON driver documentation
>
>  ogr2ogr "streets.shp" ESRIJSON:"
> https://services1.arcgis.com/dLpFH5mwVvxSN4OE/arcgis/rest/services/Street_Centerlines/FeatureServer/0/query?where=objectid+%3D+objectid=*=json=OBJECTID+ASC;
> -overwrite -oo FEATURE_SERVER_PAGING=YES
>
> Reading the documentation though, it sounds as though ogr2ogr should be
> paging through the feature service to collect the full set of features,
> which ogrinfo says number 10,954.  Setting resultOffeset parameter to 5000
> results in a new set of 5000 features. I have a lot of feature services to
> pull data from though so I'd like to be able to set ogr2ogr to page through
> the full feature set for each service rather than calculating the offsets
> and running multiple queries each time.
>
> Thanks for any suggestions.
>
> As a note, in case it makes a difference, I'm using shp here for
> simplicity but the actual destination will be a postgres db.
>
> ___
> 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
>


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

Re: [gdal-dev] read ESRIJSON with ogr2ogr

[Even Rouault]

Hugh,

I've queued in https://github.com/OSGeo/gdal/pull/4418 a fix for that.

But there's a simple workaround. Just remove the ESRIJSON: prefix in the 
connection string. In that instance, the driver will be automatically 
detected


Even

Le 02/09/2021 à 19:30, Hugh Kelley a écrit :

Hi all,

I'd like to load some data directly from an arcgis REST feature 
service using ogr2ogr.


The command that follows collects exactly 5000 features, which i 
assume is the server limit mentioned in the ESRIJSON driver documentation


 ogr2ogr "streets.shp" 
ESRIJSON:"https://services1.arcgis.com/dLpFH5mwVvxSN4OE/arcgis/rest/services/Street_Centerlines/FeatureServer/0/query?where=objectid+%3D+objectid=*=json=OBJECTID+ASC 
" 
-overwrite -oo FEATURE_SERVER_PAGING=YES


Reading the documentation though, it sounds as though ogr2ogr should 
be paging through the feature service to collect the full set of 
features, which ogrinfo says number 10,954.  Setting resultOffeset 
parameter to 5000 results in a new set of 5000 features. I have a lot 
of feature services to pull data from though so I'd like to be able to 
set ogr2ogr to page through the full feature set for each service 
rather than calculating the offsets and running multiple queries each 
time.


Thanks for any suggestions.

As a note, in case it makes a difference, I'm using shp here for 
simplicity but the actual destination will be a postgres db.


___
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

[gdal-dev] read ESRIJSON with ogr2ogr

[Hugh Kelley]

Hi all,

I'd like to load some data directly from an arcgis REST feature service
using ogr2ogr.

The command that follows collects exactly 5000 features, which i assume is
the server limit mentioned in the ESRIJSON driver documentation

 ogr2ogr "streets.shp" ESRIJSON:"
https://services1.arcgis.com/dLpFH5mwVvxSN4OE/arcgis/rest/services/Street_Centerlines/FeatureServer/0/query?where=objectid+%3D+objectid=*=json=OBJECTID+ASC;
-overwrite -oo FEATURE_SERVER_PAGING=YES

Reading the documentation though, it sounds as though ogr2ogr should be
paging through the feature service to collect the full set of features,
which ogrinfo says number 10,954.  Setting resultOffeset parameter to 5000
results in a new set of 5000 features. I have a lot of feature services to
pull data from though so I'd like to be able to set ogr2ogr to page through
the full feature set for each service rather than calculating the offsets
and running multiple queries each time.

Thanks for any suggestions.

As a note, in case it makes a difference, I'm using shp here for simplicity
but the actual destination will be a postgres db.
___
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

[Momtchil Momtchev]

    +1 from Node.js

    (fixed an issue with a few unit tests for AutoIdentifyEPSG)


On 02/09/2021 08:54, Even Rouault wrote:

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


--
Momtchil Momtchev 

___
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

[Daniel Morissette]

+1

Daniel


On 2021-09-02 02:54, Even Rouault wrote:

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




--
Daniel Morissette
Mapgears Inc
T: +1 418-696-5056 #201
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] test failures on pkgsrc build of 3.3.2rc3

[Greg Troxel]

Even Rouault  writes:

>> What's wrong with just always doing the stat?
> Nothing, but just one extra system call in a performance critical path.

OK - but do you really think that in an entire sequence of
fopen/fread/prcoess-data that one more stat (which will be cached w.r.t
the inode read in open) is going to even be measurable?  (No, I haven't
benchmarked it either.)   But I'm not the one maintaining the more
complicated code...



signature.asc
Description: PGP signature
___
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: promote GDAL 3.3.2 RC3

[Even Rouault]

Hi Sean,

sure we can delay a bit the release of the final tarballs. Anyway as we 
have the minimum 2 business day rule to pass a motion, this won't be 
before Monday. Those issues with axis order seem to be a never ending 
source of annoyance. Were existing before I got into the geo-business 
and will probably be still there when I retire...


I didn't anticipate that change to break rasterio, although those type 
of changes tend to have tricky consequences, but at the same time having 
AutoIdentifyEPSG() putting EPSG:4326 on a CRS with "wrong" axis order 
caused other issues.


Even


Le 02/09/2021 à 17:19, Sean Gillies a écrit :
Oops, forgot to reply to the list. Also, to be more specific, could we 
hold 3.3.2 until Monday, September 6?


On Thu, Sep 2, 2021 at 9:10 AM Sean Gillies > wrote:


I wish I'd noticed the change around EPSG:4326 sooner. I didn't
see a particular announcement, but the breakage was obvious in
rasterio's CI builds with GDAL master and I should have been
watching more closely.

If people update GDAL to 3.3.2 they may break their applications
that use rasterio. We'll probably be able to get a new version out
by the end of the week or beginning of next week. Could we hold
the release a few more days?

On Thu, Sep 2, 2021 at 12:54 AM Even Rouault
mailto:even.roua...@spatialys.com>>
wrote:

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


-- 
Sean Gillies




--
Sean Gillies


--
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] Motion: promote GDAL 3.3.2 RC3

[Sean Gillies via gdal-dev]

Oops, forgot to reply to the list. Also, to be more specific, could we hold
3.3.2 until Monday, September 6?

On Thu, Sep 2, 2021 at 9:10 AM Sean Gillies  wrote:

> I wish I'd noticed the change around EPSG:4326 sooner. I didn't see a
> particular announcement, but the breakage was obvious in rasterio's CI
> builds with GDAL master and I should have been watching more closely.
>
> If people update GDAL to 3.3.2 they may break their applications that use
> rasterio. We'll probably be able to get a new version out by the end of the
> week or beginning of next week. Could we hold the release a few more days?
>
> On Thu, Sep 2, 2021 at 12:54 AM Even Rouault 
> wrote:
>
>> 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
>>
>
> --
> Sean Gillies
>


-- 
Sean Gillies
___
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

[Howard Butler]

> On Sep 2, 2021, at 1:54 AM, Even Rouault  wrote:
> 
> 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

+1

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

[gdal-dev] Re Motion: promote GDAL 3.3.2 RC3

[Rahkonen Jukka (MML)]

+1

-Jukka Rahkonen-

-Alkuperäinen viesti-
Lähettäjä: gdal-dev  Puolesta Even Rouault
Lähetetty: torstai 2. syyskuuta 2021 9.54
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] Motion: promote GDAL 3.3.2 RC3

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

[gdal-dev] Motion: promote GDAL 3.3.2 RC3

[Even Rouault]

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