[gdal-dev] Esri JSON Curves

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

[gdal-dev] Esri JSON Curves

James Klassen-2
Has anyone looked at reading curved geometries from an Esri rest service queried with "returnTrueCurves=true"? 

My end goal is to import the data into PostGIS. We were successful using ogr2ogr to translate the curved features from a geodatabase download in the past, but that download is being replaced with a rest service.  OGR reads the rest service correctly without "returnTrueCurves=true", but we would like to preserve the integrity of the curves in the source data if possible.

It doesn't look like there is any code in GDAL 2.2 to deal with this situation.  `ogresrijsonreader.cpp:OGRESRIJSONReadPolygon()` looks like it is only looking for a "rings" member, not "curveRings", etc.

I am seeing the response with curves is still identified as a polygon layer:

 "geometryType": "esriGeometryPolygon"

where some of the geometries are normal polygons as (I've changed the numbers to protect the innocent):

 "geometry": {
    "rings": [
     [
      [
       544413.0,
       198310.9
      ],
...

while some of the other geometries confuse OGR and are as follows:

   "geometry": {
    "curveRings": [
     [
      [
       583150.8,
       150314.1
      ],
      {
       "c": [
        [
         583162.9,
         150317.4
        ],
        [
         583190.8,
         150313.8
        ]
       ]
      },
      [
       583141.3,
       150317.0
      ],
...

_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Esri JSON Curves

Even Rouault-2
On jeudi 19 octobre 2017 13:38:38 CEST James Klassen wrote:

> Has anyone looked at reading curved geometries from an Esri rest service
> queried with "returnTrueCurves=true"?
>
> My end goal is to import the data into PostGIS. We were successful using
> ogr2ogr to translate the curved features from a geodatabase download in the
> past, but that download is being replaced with a rest service.  OGR reads
> the rest service correctly without "returnTrueCurves=true", but we would
> like to preserve the integrity of the curves in the source data if possible.
>
> It doesn't look like there is any code in GDAL 2.2 to deal with this
> situation.  `ogresrijsonreader.cpp:OGRESRIJSONReadPolygon()` looks like it
> is only looking for a "rings" member, not "curveRings", etc.

This is indeed not supported at the moment.
It appears to be documented in
<a href="http://resources.arcgis.com/en/help/arcgis-rest-api/index.html#//02r3000000n1000000#CURVE">http://resources.arcgis.com/en/help/arcgis-rest-api/index.html#//02r3000000n1000000#CURVE

The data model is, non suprisingly, super close to what exists in Personnal Geodatabase
or FileGeodatabase. Arc/CircularArc could be translated to CIRCULARSTRING/COMPOUNDCURVE/
CURVEPOLYGON. Bezier curves would have to be linearized since there's no equivalent in
OGC SF / ISO SQL-MM Part 3 standards.
So this is "just" a matter of coding it.

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Esri JSON Curves

James Klassen-2
On Thu, Oct 19, 2017 at 2:04 PM, Even Rouault <[hidden email]> wrote:
On jeudi 19 octobre 2017 13:38:38 CEST James Klassen wrote:
> Has anyone looked at reading curved geometries from an Esri rest service
> queried with "returnTrueCurves=true"?
>
> My end goal is to import the data into PostGIS. We were successful using
> ogr2ogr to translate the curved features from a geodatabase download in the
> past, but that download is being replaced with a rest service.  OGR reads
> the rest service correctly without "returnTrueCurves=true", but we would
> like to preserve the integrity of the curves in the source data if possible.
>
> It doesn't look like there is any code in GDAL 2.2 to deal with this
> situation.  `ogresrijsonreader.cpp:OGRESRIJSONReadPolygon()` looks like it
> is only looking for a "rings" member, not "curveRings", etc.

This is indeed not supported at the moment.
It appears to be documented in
http://resources.arcgis.com/en/help/arcgis-rest-api/index.html#//02r3000000n1000000#CURVE

The data model is, non suprisingly, super close to what exists in Personnal Geodatabase
or FileGeodatabase. Arc/CircularArc could be translated to CIRCULARSTRING/COMPOUNDCURVE/
CURVEPOLYGON. Bezier curves would have to be linearized since there's no equivalent in
OGC SF / ISO SQL-MM Part 3 standards.
So this is "just" a matter of coding it.


Interesting.  So, some new JSON parsing code feeding into similar code to what already exists in other drivers to create the right OGR objects.  It just comes down to time and/or money to actually implement it.


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Esri JSON Curves

James Klassen-2
I finally got around to doing a rough implementation of parsing ESRIJSON with curved geometries.  The code is very rough yet, but works enough to import a polygon layer from an ESRI FeatureService into PostGIS with the curves intact.  Code is available at [1].

Main issues:

I don't know how to detect if there will be curves in the source file without first parsing the whole file, so currently I just assume a curved geometry type.  This might be a candidate for an open option.

My focus has been on polygon layers (because that's the dataset I need to read).  I doubt it works outside of polygon layers at the moment.

I had to enable the "Curve Geometries" capability in the top level GeoJSON driver (which may break some things for the GeoJSON/TopoJSON drivers).

Memory management and error handling need to be improved.

I only implemented circular curves ("c").  There are other curve types supported by the spec, (e.g. Bézier), but I don't have any examples of these other types in the datasets I have on hand.

On Thu, Oct 19, 2017 at 4:55 PM, James Klassen <[hidden email]> wrote:
On Thu, Oct 19, 2017 at 2:04 PM, Even Rouault <[hidden email]> wrote:
On jeudi 19 octobre 2017 13:38:38 CEST James Klassen wrote:
> Has anyone looked at reading curved geometries from an Esri rest service
> queried with "returnTrueCurves=true"?
>
> My end goal is to import the data into PostGIS. We were successful using
> ogr2ogr to translate the curved features from a geodatabase download in the
> past, but that download is being replaced with a rest service.  OGR reads
> the rest service correctly without "returnTrueCurves=true", but we would
> like to preserve the integrity of the curves in the source data if possible.
>
> It doesn't look like there is any code in GDAL 2.2 to deal with this
> situation.  `ogresrijsonreader.cpp:OGRESRIJSONReadPolygon()` looks like it
> is only looking for a "rings" member, not "curveRings", etc.

This is indeed not supported at the moment.
It appears to be documented in
http://resources.arcgis.com/en/help/arcgis-rest-api/index.html#//02r3000000n1000000#CURVE

The data model is, non suprisingly, super close to what exists in Personnal Geodatabase
or FileGeodatabase. Arc/CircularArc could be translated to CIRCULARSTRING/COMPOUNDCURVE/
CURVEPOLYGON. Bezier curves would have to be linearized since there's no equivalent in
OGC SF / ISO SQL-MM Part 3 standards.
So this is "just" a matter of coding it.


Interesting.  So, some new JSON parsing code feeding into similar code to what already exists in other drivers to create the right OGR objects.  It just comes down to time and/or money to actually implement it.



_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Esri JSON Curves

Even Rouault-2
On vendredi 22 juin 2018 14:38:15 CEST James Klassen wrote:

> I finally got around to doing a rough implementation of parsing ESRIJSON
> with curved geometries.  The code is very rough yet, but works enough to
> import a polygon layer from an ESRI FeatureService into PostGIS with the
> curves intact.  Code is available at [1].
>
> Main issues:
>
> I don't know how to detect if there will be curves in the source file
> without first parsing the whole file, so currently I just assume a curved
> geometry type.  This might be a candidate for an open option.

The ESRI Json reader ingests everything in memory and builds the JSon tree
structure, so doing an initial pass by default shouldn't be a big deal.

>
> My focus has been on polygon layers (because that's the dataset I need to
> read).  I doubt it works outside of polygon layers at the moment.
>
> I had to enable the "Curve Geometries" capability in the top level GeoJSON
> driver (which may break some things for the GeoJSON/TopoJSON drivers).

If my memories are right, you only need to set it for write support. So
shouldn't be needed there.

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Esri JSON Curves

James Klassen-2


On 06/22/2018 02:51 PM, Even Rouault wrote:

> On vendredi 22 juin 2018 14:38:15 CEST James Klassen wrote:
>> I finally got around to doing a rough implementation of parsing ESRIJSON
>> with curved geometries.  The code is very rough yet, but works enough to
>> import a polygon layer from an ESRI FeatureService into PostGIS with the
>> curves intact.  Code is available at [1].
>>
>> Main issues:
>>
>> I don't know how to detect if there will be curves in the source file
>> without first parsing the whole file, so currently I just assume a curved
>> geometry type.  This might be a candidate for an open option.
> The ESRI Json reader ingests everything in memory and builds the JSon tree
> structure, so doing an initial pass by default shouldn't be a big deal.

This would still be an issue with paging.  Most of the actual datasets
of interest (to me) involve multiple HTTP requests to fetch many pages
of JSON data (usually 1000 - 10000 features at a time depending on
server setup).  The curves may easily not be on the first page and
re-running the whole request is expensive.

>> My focus has been on polygon layers (because that's the dataset I need to
>> read).  I doubt it works outside of polygon layers at the moment.
>>
>> I had to enable the "Curve Geometries" capability in the top level GeoJSON
>> driver (which may break some things for the GeoJSON/TopoJSON drivers).
> If my memories are right, you only need to set it for write support. So
> shouldn't be needed there.
>

All I know is that without it set, the curved geometries were linearized
somewhere in OGR before they were passed to the PostGIS driver.

_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Esri JSON Curves

Even Rouault-2
> This would still be an issue with paging.  Most of the actual datasets
> of interest (to me) involve multiple HTTP requests to fetch many pages
> of JSON data (usually 1000 - 10000 features at a time depending on
> server setup).  The curves may easily not be on the first page and
> re-running the whole request is expensive.

Fair enough

> > If my memories are right, you only need to set it for write support. So
> > shouldn't be needed there.
>
> All I know is that without it set, the curved geometries were linearized
> somewhere in OGR before they were passed to the PostGIS driver.

You should double check and spot where this comes from.
You can set a breakpoint on OGRGeometryFactory::curveToLineString which should
be taken when linearization occurs.

As an experience, I've disabled OLCCurveGeometries and ODsCCurveGeometries
capability declaration in the CSV driver, and no linearization occurs when
converting to PostGIS

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

[gdal-dev] Esri JSON Curves

James Klassen-2

On Mon, Jun 25, 2018 at 4:14 PM, Even Rouault
<[hidden email] <mailto:[hidden email]>> wrote:


    > > If my memories are right, you only need to set it for write
    support. So
    > > shouldn't be needed there.
    >
    > All I know is that without it set, the curved geometries were
    linearized
    > somewhere in OGR before they were passed to the PostGIS driver.

    You should double check and spot where this comes from.
    You can set a breakpoint on OGRGeometryFactory::curveToLineString
    which should
    be taken when linearization occurs.

    As an experience, I've disabled OLCCurveGeometries and
    ODsCCurveGeometries
    capability declaration in the CSV driver, and no linearization
    occurs when
    converting to PostGIS


I've narrowed it down some more... it looks like OLCCurveGeometries is
necessary for the geometry type to be passed correctly to PostGIS.
ODsCCurveGeometries doesn't seem to matter.

Command:
gdb --args ${OGR2OGR} \
    -overwrite \
    Pg: \
    "${SRC_URL}" \
    -nln temp.parcels_test \
    -nlt PROMOTE_TO_MULTI \
    ESRIJSON
break OGRGeometryFactory::curveToLineString
run


With OLCCurveGeometries and ODsCCurveGeometries false, I get the following:

Warning 1: Geometry to be inserted is of type Multi Polygon, whereas the
layer geometry type is Multi Surface.
Insertion is likely to fail
ERROR 1: COPY statement failed.
ERROR:  Geometry type (MultiPolygon) does not match column type
(MultiSurface)
CONTEXT:  COPY parcels_test, line 1, column wkb_geometry:
"010600002032BF0D000100000001030000000100000007000000803E1A3ACD582241005A55E36CF00A4100DF0D0B13582241..."

With OLCCurveGeometries false and ODsCCurveGeometries true:

Warning 1: Geometry to be inserted is of type Multi Polygon, whereas the
layer geometry type is Multi Surface.
Insertion is likely to fail
ERROR 1: COPY statement failed.
ERROR:  Geometry type (MultiPolygon) does not match column type
(MultiSurface)
CONTEXT:  COPY parcels_test, line 1, column wkb_geometry:
"010600002032BF0D000100000001030000000100000007000000803E1A3ACD582241005A55E36CF00A4100DF0D0B13582241..."

With OLCCurveGeometries true and ODsCCurveGeometries false:

No Warning.
Works as expected.

With OLCCurveGeometries true and ODsCCurveGeometries true:

No Warning.
Works as expected.


In the first two cases (without OLCCurveGeometries set) I see
curveToLineString is being called when there are curves in the data, but
not on every result page (again curves are relatively rare in the dataset).


(gdb) bt
#0  0x00007ffff6f66f50 in OGRGeometryFactory::curveToLineString(double,
double, double, double, double, double, double, double, double, int,
double, char const* const*)@plt () from
/srv/www/apps/ogr-esricurve/lib/libgdal.so.20
#1  0x00007ffff6fadf37 in OGRCircularString::CurveToLine (this=0x10436d0,
    dfMaxAngleStepSizeDegrees=0, papszOptions=0x0) at
ogrcircularstring.cpp:677
#2  0x00007ffff6fb04a2 in OGRCompoundCurve::CurveToLineInternal (
    this=0x10435e0, dfMaxAngleStepSizeDegrees=0, papszOptions=0x0,
    bIsLinearRing=<optimized out>) at ogrcompoundcurve.cpp:357
#3  0x00007ffff6fb55f7 in OGRCurvePolygon::CurvePolyToPoly (this=0x10435b0,
    dfMaxAngleStepSizeDegrees=0, papszOptions=0x0) at
ogrcurvepolygon.cpp:578
#4  0x00007ffff6fd7ae2 in OGRGeometryFactory::forceToPolygon
(poGeom=0x10435b0)
    at ogrgeometryfactory.cpp:688
#5  0x00007ffff6fd9118 in OGRGeometryFactory::forceTo (poGeom=0x10435b0,
    eTargetType=eTargetType@entry=wkbPolygon,
    papszOptions=papszOptions@entry=0x0) at ogrgeometryfactory.cpp:4494
#6  0x00007ffff7641bcc in OGRLayer::ConvertGeomsIfNecessary (
    this=this@entry=0x2bd3320, poFeature=poFeature@entry=0xf7f790)
    at ogrlayer.cpp:576
#7  0x00007ffff7641bf1 in OGRLayer::SetFeature (this=0x2bd3320,
    poFeature=0xf7f790) at ogrlayer.cpp:590
#8  0x00007ffff75e25a9 in OGRGeoJSONLayer::AddFeature (this=0x2bd3320,
    poFeature=poFeature@entry=0xf7f790) at ogrgeojsonlayer.cpp:513
#9  0x00007ffff75da482 in OGRESRIJSONReader::AddFeature (this=<optimized
out>,
---Type <return> to continue, or q <return> to quit---
    poFeature=0xf7f790) at ogresrijsonreader.cpp:287
#10 0x00007ffff75dbcfd in OGRESRIJSONReader::ReadFeatureCollection (
    this=this@entry=0x7fffffffd6c0, poObj=<optimized out>)
    at ogresrijsonreader.cpp:464
#11 0x00007ffff75dbdfb in OGRESRIJSONReader::ReadLayers
(this=0x7fffffffd6c0,
    poDS=0x1679750, eSourceType=<optimized out>) at
ogresrijsonreader.cpp:139
#12 0x00007ffff75defeb in OGRGeoJSONDataSource::LoadLayers (
    this=this@entry=0x1679750, poOpenInfo=poOpenInfo@entry=0x7fffffffd860,
    nSrcType=nSrcType@entry=eGeoJSONSourceService,
    pszUnprefixed=pszUnprefixed@entry=0x15ecd20 "https://maps..."...,
pszJSonFlavor=pszJSonFlavor@entry=0x1c4e628 "ESRIJSON")
    at ogrgeojsondatasource.cpp:785
#13 0x00007ffff75dffa0 in OGRGeoJSONDataSource::Open (
    this=this@entry=0x1679750, poOpenInfo=poOpenInfo@entry=0x7fffffffd860,
    nSrcType=eGeoJSONSourceService, pszJSonFlavor=0x1c4e628 "ESRIJSON")
    at ogrgeojsondatasource.cpp:179
#14 0x00007ffff75e133e in OGRESRIFeatureServiceDataset::LoadPage (
    this=0x6956e0) at ogrgeojsondriver.cpp:408
#15 0x00007ffff75e14e7 in OGRESRIFeatureServiceDataset::LoadNextPage (
    this=<optimized out>) at ogrgeojsondriver.cpp:390
#16 0x00007ffff75e1628 in OGRESRIFeatureServiceLayer::GetNextFeature (
---Type <return> to continue, or q <return> to quit---
    this=0x9009c0) at ogrgeojsondriver.cpp:177
#17 0x00007ffff70b90a9 in LayerTranslator::Translate (
    this=this@entry=0x7fffffffdd20, poFeatureIn=poFeatureIn@entry=0x0,
    psInfo=psInfo@entry=0x29ae270, nCountLayerFeatures=0,
    pnReadFeatureCount=pnReadFeatureCount@entry=0x0,
    nTotalEventsDone=@0x7fffffffdb58: 0, pfnProgress=0x0, pProgressArg=0x0,
    psOptions=0x6960b0) at ogr2ogr_lib.cpp:4392
#18 0x00007ffff70c0779 in GDALVectorTranslate (pszDest=<optimized out>,
    hDstDS=hDstDS@entry=0x0, nSrcCount=nSrcCount@entry=1,
    pahSrcDS=pahSrcDS@entry=0x7fffffffdeb0,
    psOptionsIn=psOptionsIn@entry=0x693b40,
    pbUsageError=pbUsageError@entry=0x7fffffffdeac) at ogr2ogr_lib.cpp:3060
#19 0x00000000004019e7 in main (nArgc=<optimized out>, papszArgv=0x693ae0)
    at ogr2ogr_bin.cpp:412


In the last two cases (with OLCCurveGeometries set) I see
curveToLineString is being called with a different back trace (related
to OGRGeometryFactory::organizePolygons):

#0  0x00007ffff6f66f50 in OGRGeometryFactory::curveToLineString(double,
double, double, double, double, double, double, double, double, int,
double, char const* const*)@plt () from
/srv/www/apps/ogr-esricurve/lib/libgdal.so.20
#1  0x00007ffff6fadf37 in OGRCircularString::CurveToLine
(this=0x19ce4d0, dfMaxAngleStepSizeDegrees=0, papszOptions=0x0) at
ogrcircularstring.cpp:677
#2  0x00007ffff6fb04a2 in OGRCompoundCurve::CurveToLineInternal
(this=0x19ce3e0, dfMaxAngleStepSizeDegrees=0, papszOptions=0x0,
    bIsLinearRing=<optimized out>) at ogrcompoundcurve.cpp:357
#3  0x00007ffff6fd2f95 in OGRGeometryFactory::organizePolygons
(papoPolygons=papoPolygons@entry=0x19ce390,
nPolygonCount=nPolygonCount@entry=2,
    pbIsValidGeometry=pbIsValidGeometry@entry=0x0,
papszOptions=papszOptions@entry=0x0) at ogrgeometryfactory.cpp:1537
#4  0x00007ffff75daff7 in OGRESRIJSONReadPolygon
(poObj=poObj@entry=0x1e50050) at ogresrijsonreader.cpp:1070
#5  0x00007ffff75db761 in OGRESRIJSONReader::ReadGeometry
(this=this@entry=0x7fffffffd6c0, poObj=poObj@entry=0x1e50050) at
ogresrijsonreader.cpp:307
#6  0x00007ffff75db990 in OGRESRIJSONReader::ReadFeature
(this=this@entry=0x7fffffffd6c0, poObj=poObj@entry=0x1e4a590) at
ogresrijsonreader.cpp:415
#7  0x00007ffff75dbcf2 in OGRESRIJSONReader::ReadFeatureCollection
(this=this@entry=0x7fffffffd6c0, poObj=<optimized out>)
    at ogresrijsonreader.cpp:463
#8  0x00007ffff75dbdfb in OGRESRIJSONReader::ReadLayers
(this=0x7fffffffd6c0, poDS=0x3433f70, eSourceType=<optimized out>)
    at ogresrijsonreader.cpp:139
#9  0x00007ffff75defeb in OGRGeoJSONDataSource::LoadLayers
(this=this@entry=0x3433f70, poOpenInfo=poOpenInfo@entry=0x7fffffffd860,
    nSrcType=nSrcType@entry=eGeoJSONSourceService,
    pszUnprefixed=pszUnprefixed@entry=0x2c2f680 "https://maps...."...,
    pszJSonFlavor=pszJSonFlavor@entry=0x1011c48 "ESRIJSON") at
ogrgeojsondatasource.cpp:785
#10 0x00007ffff75dffa0 in OGRGeoJSONDataSource::Open
(this=this@entry=0x3433f70, poOpenInfo=poOpenInfo@entry=0x7fffffffd860,
    nSrcType=eGeoJSONSourceService, pszJSonFlavor=0x1011c48 "ESRIJSON")
at ogrgeojsondatasource.cpp:179
#11 0x00007ffff75e133e in OGRESRIFeatureServiceDataset::LoadPage
(this=0x6956e0) at ogrgeojsondriver.cpp:408
#12 0x00007ffff75e14e7 in OGRESRIFeatureServiceDataset::LoadNextPage
(this=<optimized out>) at ogrgeojsondriver.cpp:390
#13 0x00007ffff75e1628 in OGRESRIFeatureServiceLayer::GetNextFeature
(this=0x9009c0) at ogrgeojsondriver.cpp:177
#14 0x00007ffff70b90a9 in LayerTranslator::Translate
(this=this@entry=0x7fffffffdd20, poFeatureIn=poFeatureIn@entry=0x0,
    psInfo=psInfo@entry=0x2bb59c0, nCountLayerFeatures=0,
pnReadFeatureCount=pnReadFeatureCount@entry=0x0,
nTotalEventsDone=@0x7fffffffdb58: 6000,
    pfnProgress=0x0, pProgressArg=0x0, psOptions=0x6960b0) at
ogr2ogr_lib.cpp:4392
#15 0x00007ffff70c0779 in GDALVectorTranslate (pszDest=<optimized out>,
hDstDS=hDstDS@entry=0x0, nSrcCount=nSrcCount@entry=1,
    pahSrcDS=pahSrcDS@entry=0x7fffffffdeb0,
psOptionsIn=psOptionsIn@entry=0x693b40,
pbUsageError=pbUsageError@entry=0x7fffffffdeac)
    at ogr2ogr_lib.cpp:3060
#16 0x00000000004019e7 in main (nArgc=<optimized out>,
papszArgv=0x693ae0) at ogr2ogr_bin.cpp:412
(gdb) cont
Continuing.
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Esri JSON Curves

Even Rouault-2
>
> In the first two cases (without OLCCurveGeometries set) I see
> curveToLineString is being called when there are curves in the data, but
> not on every result page (again curves are relatively rare in the dataset).

ok, then replace the call to OGRMemLayer::SetFeature() with
OGRMemLayer::ISetFeature() in ogrgeojsonlayer.cpp to shortcut the
linearization that is done by the generic OGRLayer::SetFeature()

And you can then remove OLCCurveGeometries


> In the last two cases (with OLCCurveGeometries set) I see
> curveToLineString is being called with a different back trace (related
> to OGRGeometryFactory::organizePolygons):

That one is fine. It is an implementation detail of organizePolygons()

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Esri JSON Curves

James Klassen-2
Ok.  I made that change and it appears to work.

Latest code available here: https://github.com/klassenjs/gdal/tree/esrijson-curves

On Mon, Jul 2, 2018 at 1:56 PM, Even Rouault <[hidden email]> wrote:
>
> In the first two cases (without OLCCurveGeometries set) I see
> curveToLineString is being called when there are curves in the data, but
> not on every result page (again curves are relatively rare in the dataset).

ok, then replace the call to OGRMemLayer::SetFeature() with
OGRMemLayer::ISetFeature() in ogrgeojsonlayer.cpp to shortcut the
linearization that is done by the generic OGRLayer::SetFeature()

And you can then remove OLCCurveGeometries


> In the last two cases (with OLCCurveGeometries set) I see
> curveToLineString is being called with a different back trace (related
> to OGRGeometryFactory::organizePolygons):

That one is fine. It is an implementation detail of organizePolygons()

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


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev