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: | |
Cc: |
Description
Hi,
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 MultiPoint element when .xsd exists
- contains Point element when .xsd disappears
Can you help explain me why we have the difference outcome here ?
Attachments (2)
Change History (5)
by , 11 years ago
comment:1 by , 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 , 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 , 11 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
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
The GML file