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

[Even Rouault]

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.
>
> intOGRMiraMonDataSource::Open(constchar*pszFilename, VSILFILE*fp,
>
> constOGRSpatialReference*poSRS, intbUpdateIn,
>
> */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>
> *Enviado el:* dimarts, 12 de desembre de 2023 13:17
> *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
>
> 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/94a004c4/attachment.htm>