Developer Discussions

[Jacques]

Hi guys.

I created a redline entry for capturing data.

I am able to insert geometries no problem.

But when I try to download them as shapefile the shapefile downloads fine byt they are empty.

I also tried this on my WFS service with no issue only shapefiles from redlining is empty.

I get no errors, any idea what could be causing this behaviour?

I am using Portal SDK ver 15.5.0105 build 00054

Any help would be greatly appreciated.

Kind Regards

Jacques

[jan.neumann]

Hi Jacques,

Is this a custom tool developed on top of SDK Portal? If so, you should inspect what data comes to GDAL components via solution debugging.

Regards,

Jan

[Jacques]

 Hi Jan,

As far as I can remember Portal SDK creates the download as shapefile by default for PSS services.

I just created a script to create a pss with feature some feature classes.

Kind Regards

Jacques

[lukasz.baraniak]

What you are experiencing is caused by using too new a version of GDAL :-). The example provided with the SDK named "Download as Shapefiles" was created when GDAL 1.x was available and the GeoJSON spec was the 2008 one. This spec made it possible for GeoJSON geometries to be in arbitrary projections. This required the use of the crsId attribute containing a declaration about the CRS the geometry is in. In 2016 the IETF standardized GeoJSON as RFC 7946 and dropped the possibility of declaring arbitrary CRSes in lieu of mandating the use of long/lat WGS:84 coordinates. That's when ogr2ogr stopped understanding the GeoJSON that Portal API produces by default.
Things to try:
1. Use a pre-2016 GeoJSON standard GDAL
2. Enhance the Portal frontend JavaScript extensions to transform the coordinates into WGS:84
3. Tinker with the format converter handler on the backend to supply a source CRS name to ogr2ogr

[Jacques]

Hi Lukasz,

Thanks,I will give each option a go and report back.

Thanks for the information.

Kind Regards

Jacques

[Jacques]

Hi Lukasz,

Just a question on what you said.

Looking at the possible solutions I understand what you are saying , but is the WFS download to shapefile being altered before downloading or the srs passes where the PSS services is not?

Because WFS downloads fine but not PSS.

Geospatial Portal active map window Epsg:3857 , so does this mean that data stored in PSS wil be stored as 3857 and data services from WFS will use service source SRS that is in our case indeed EPSG:4326 WGS84?

This is the only way I can see it work given the issue PSS not forming?

Looking forward to your response.

Kind Regards

Jacques

[Jacques]

Hi Lukasz,

I checked my GDAL version and it is an older version (1.11.1)

GDAL.PNG ‏10 KB

[lukasz.baraniak]

Oh. I might've jumped to conclusions a bit too early after giving the SDK example one go and arriving at the same symptoms as yours. I.e. I've gotten an empty, schema correct shapefile, but it is caused by the fact that ogr2ogr refused to convert geometries. The coordinates were out of bounds for the WGS:84 CRS.

It seems you'd need to debug the FormatConverter handler on the Portal SDK instance's backend side to see exactly what went wrong with the ogr2ogr.exe call. You could do that by reading the process' redirected StandardOutput and StandardError. Or transferring that to a file somewhere:

    public class GdalJsonToShapefileConverter: GdalConverterBase, IGeoJsonToShapefileConverter
    {
        // ... cut for brevity ...
        protected override Stream InvokeConvert(params string[] options)
        {
            // ... cut for brevity ...
            p.Start();
            while (true)
            {
                var waitForExit = p.WaitForExit(Timeout);
                if (waitForExit)
                    break;
            }
            
            // add these lines to drop the standard output and error streams to files:
            File.WriteAllText(@"C:\temp\fc_ogr2ogr_stderr.txt", p.StandardError.ReadToEnd());
            File.WriteAllText(@"C:\temp\fc_ogr2ogr_stdout.txt", p.StandardOutput.ReadToEnd());

This way, the C:\temp\fc_ogr2ogr_stderr.txt and fc_ogr2ogr_stdout.txt files will contain the latest messages output by the ogr2ogr.exe invoked.

[Jacques]

Thanks Lukasz,

I will go through the info you supplied.

What I see happeniing is the following:

Here is the response string

?context.Request.Params["geoJSON"] (WFS)

"{\"type\":\"FeatureCollection\",\"features\":[{\"type\":\"Feature\",\"geometry\":{\"type\":\"Point\",\"coordinates\":[2538894.34836217,-3462816.49720881],\"crsId\":\"EPSG:3857\",\"rotation\":0},\"properties\":{\"{http://www.opengis.net/gml}id\":\"ParentFarm.1\",\"{http://www.intergraph.com/geomedia/gml}ID\":\"1\...",\"{http://www.intergraph.com/geomedia/gml}Longitude\":\"22.8072759789841\"}},{\"type\":\"Feature\",\"ge...[2985642.00269831,-3052161.96628372],\"crsId\":\"EPSG:3857\",\"rotation\":0},\"properties\":{\"{http://www.opengis.net/gml}id\":\"ParentFarm.18\",\"{http://www.intergraph.com/geomedia/gml}ID\":\"1... Ridge\",\"{http://www.intergraph.com/geomedia/gml}FarmSize\":\"1090\",\"{http://www.intergrap

h.com/geomedia/gml}Latitude\":\"-26.427791595459\",\"{http://www.intergraph.com/geomedia/gml}Longitude\":\"26.8204784393311\"}},{\"type\":\"Feature\",\"ge...[3149333.38504656,-2972743.93337347],\"crsId\":\"EPSG:3857\",\"rotation\":0},\"properties\":{\"{http://www.opengis.net/gml}id\":\"ParentFarm.57\",\"{http://www.intergraph.com/geomedia/gml}ID\":\"5...",\"{http://www.intergraph.com/geomedia/gml}Longitude\":\"28.290943145752\"}},{\"type\":\"Feature\",\"geo...[3182258.21033024,-2769286.87294897],\"crsId\":\"EPSG:3857\",\"rotation\":0},\"properties\":{\"{http://www.opengis.net/gml}id\":\"ParentFarm.60\",\"{http://www.intergraph.com/geomedia/gml}ID\":\"6... Moia\",\"{http://www.

intergraph.com/geomedia/gml}FarmSize\":\"2000\",\"{http://www.intergraph.com/geomedia/gml}Latitude\":\"-24.1302433013916\",\"{http://www.intergraph.com/geomedia/gml}Longitude\":\"28.5867118835449\"}}],\"id\":\"{http://www.intergraph.com/geomedia/gml}ParentFarm\"}"

?context.Request.Params["geoJSON"] (PSS)

"{\"type\":\"FeatureCollection\",\"features\":[],\"id\":\"Test\"}"

[jan.neumann]

Hi Jacques,

I have retested the case and I'm getting proper JSON generated in the temp folder, usually located:

C:\Users\[SDKAppPool]\AppData\Local\Temp\format-converter\[guid]\input.json

{
    "type": "FeatureCollection",
    "features": [{
        "type": "Feature",
        "geometry": {
            "type": "Polygon",
            "coordinates": [[[-3101452.48827496, 8249477.922467288], [-1183800.3226564582, 9306143.401481563], [-1183800.3226564582, 10284537.36353182], [-2592687.628008826, 10636759.18986991], [-3571081.590059083, 9795340.38250669], [-3101452.48827496, 8249477.922467288]]],
            "crsId": "EPSG:3857"
		},
...

Then I tried to run ogr2ogr (GDAL v1.11) from a command line but it failed:

> "C:\Program Files\GDAL\ogr2ogr.exe" -t_srs EPSG:3857 output_shapefiles input.json
Failed to reproject feature 0 (geometry probably out of source or destination SRS).
ERROR 1: Terminating translation prematurely after failed
translation of layer OGRGeoJSON (use -skipfailures to skip errors)

After that, I tried to create PSS in EPSG:4326 with following input.json file:

{
 "type": "FeatureCollection",
  "features": [{
    "type": "Feature",
      "geometry": {
        "type": "Polygon",
        "coordinates": [[[6.943865768120837, 61.7535155967375], [27.334490768120837, 61.9292968467375], [30.850115768120837, 43.4722655967375], [8.525897018120837, 45.2300780967375], [6.943865768120837, 61.7535155967375]]],
        "crsId": "EPSG:4326"
       },

And the ShapeFiles were generated without errors. I could display them back in Portal by using ShapeFile drag'n'drop import tool.

There's definitely an issue in the GDAL component here...