Opened 11 years ago

Closed 11 years ago

#4501 closed defect (wontfix)

Converting GML file with ogr2ogr.exe gives different output against the present of .xsd file

Reported by: duypl Owned by: warmerdam
Priority: normal Milestone:
Component: OGR_SF Version: 1.9.0
Severity: normal Keywords:



I'm writing a program to convert GIS files using OGR. I see an issue in OGR when reading GML file with / without its .xsd file (the .xsd file that defines the schema for the GML) but I don't know whether it is right or not.

I have an GML file and its .xsd, the GML contains one Point element and its .xsd describe that the feature contains a Point and a MultiPoint element (please see the attached files). Then I use ogr2ogr.exe to read the gml and generate the output to another GML file with below command

ogr2ogr.exe -f GML output.gml input.gml

I run above command twice but:

  • in the first time, I keep the name of gml and .xsd the same ( input.gml and input.xsd) and execute the command
  • in the second time, I remove the .xsd file and execute the command

Result: it surprises me while the input.gml contains only Point element, the output.gml is

  • contains Point element when .xsd disappears

Can you help explain me why we have the difference outcome here ?

Attachments (2)

input.gml (893 bytes ) - added by duypl 11 years ago.
The GML file
input.xsd (882 bytes ) - added by duypl 11 years ago.
The .XSD goes with the GML file

Download all attachments as: .zip

Change History (5)

by duypl, 11 years ago

Attachment: input.gml added

The GML file

by duypl, 11 years ago

Attachment: input.xsd added

The .XSD goes with the GML file

comment:1 by Even Rouault, 11 years ago

The behaviour you've noticed is expected to me.

When the .xsd is there, you can see in it that the geometry is either a point or a multipoint. So the layer is set to be of multipoint type (which is the type that can hold both points and multipoints). When a point is read, it is transformed into a multipoint to match the layer definition.

When the .xsd isn't there, OGR will have to parse the whole file to determine the best geometry type. As there's only a POINT, this will be point.

comment:2 by duypl, 11 years ago

Thanks rouault.

I see now. So OGR is trying to pick the geometry type that may suit well for most of cases.

I guess this behaviour works well for common usage. However, in my program, when it uses OGR to read the gml, it supposes the geometry type of gml file should be kept the same as in file. And this logic (pick the type can hold the most) results an error in my process flow.

Is there anyway that I can ask OGR to read the GML file as is (without replacing geometry type) ?

comment:3 by Even Rouault, 11 years ago

Resolution: wontfix
Status: newclosed

The only solution without modifying the code is removing the .xsd as you've seen.

I'm closing this ticket since I think that current behaviour is the one that will be the most appropriate for most situations. For example, this is the one you want to have if you convert to shapefile with ogr2ogr, where shapefiles don't support mix of geometry types

Note: See TracTickets for help on using tickets.