[gdal-dev] Creating a diver: specify the options to create a layer

Abel Pau a.pau at creaf.uab.cat
Tue Dec 12 08:14:46 PST 2023


Thanks,
I think it’s enough exporting one of the Z. It’s a not very used particularity of the format.

De: Even Rouault <even.rouault at spatialys.com>
Enviado el: dimarts, 12 de desembre de 2023 15:35
Para: Abel Pau <a.pau at creaf.uab.cat>; gdal-dev at lists.osgeo.org
Asunto: Re: [gdal-dev] Creating a diver: specify the options to create a layer


You could also potentially expose all the height values as a attribute of type RealList (not all OGR drivers support that though).  The open option also seems reasonable. Up to you w.r.t the use cases you've in mind.
Le 12/12/2023 à 15:02, Abel Pau a écrit :
Hi again,
thanks for the interest, Even. You’ll rest of me when I finish the driver. I promise :)

I didn’t explain it well. I try again.

Now I am in the case I want to translate from MiraMon to other GDAL formats.
For instance, points MiraMon format can have one or several Z values for each point. Then the user who wants to translate from MiraMon to other formats has to decide from command line which of Z’s wants to get.
Example:
The file MiraMoin_zPoints.pnt has 3 points:
point (2,2) has 3 heights: 8, 3.2 and 9
point (1,2) has 2 heights: 3, 8.1
point (2,4) has 1 height: 9

User has three options to get a Z for each point:
Get the first one for each point: 8, 3 and 9
Get the highest one for each point: 9, 8.1 and 9
Get the lowest one for each point: 3.2, 3 and 9

It’s a user decision. By default user will obtain the first one for each point but perhaps user wants another thing.

So, then, in a command line we could have:   ogr2ogr gml_file.gml MiraMoin_zPoints.pnt to translate from MiraMon to GML

If user wants to specify which Z wants, then this decision should be expressed in this line in some way.

After a research in the code (not documentation) I managed to get the way and now I would like to be sure that is the correct way:

ogr2ogr gml_file.gml MiraMoin_zPoints.pnt -oo Height=First, for getting the GML with the first Z of each point
ogr2ogr gml_file.gml MiraMoin_zPoints.pnt -oo Height=Hightest, for getting the GML with the highest Z of each point
ogr2ogr gml_file.gml MiraMoin_zPoints.pnt -oo Height=Lowest, for getting the GML with the lowest Z of each point

Using “-oo“, in the Open() method of MiraMon driver datasource I can retrieve this value, save it in some variable and then give, for every feature, the appropriate Z in the GetNextRawFeature() method of the layer.

int OGRMiraMonDataSource::Open(const char *pszFilename, VSILFILE *fp,
                           const OGRSpatialReference *poSRS, int bUpdateIn,
                            char **papszOpenOptionsUsr)


If it’s correct, perfect. If not, then, which way would be the appropriate?


Thanks and I hope have been clear now :)
Thanks!





De: Even Rouault <even.rouault at spatialys.com><mailto:even.rouault at spatialys.com>
Enviado el: dimarts, 12 de desembre de 2023 13:17
Para: Abel Pau <a.pau at creaf.uab.cat><mailto:a.pau at creaf.uab.cat>; gdal-dev at lists.osgeo.org<mailto:gdal-dev at lists.osgeo.org>
Asunto: Re: [gdal-dev] Creating a diver: specify the options to create a layer


Abel Pau,

Do I have to use the same to specify which height (in file with Z) I have to offer?
I have three possibilities: First Z, Highest or Lowest. I want the usem tells me what he/she wants.
How can I do that? Where can I get, then, this values?

I'm not sure to understand your question. Are those height values fields to fill in the file header?

If so, yes you may obviously offer layer creation options to fill them.  If those values are directly related with the Z component of geometries of features the user writes into the file, and you can edit the header in a post processing stage (but I believe your strategy was to write some temporary file, before the final file, so that should be possible), you could also possibly infer them from the values of the features too.
Even

--

http://www.spatialys.com

My software is free, but my time generally not.

--

http://www.spatialys.com

My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20231212/c60f8137/attachment-0001.htm>


More information about the gdal-dev mailing list