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.roua...@spatialys.com>
*Enviado el:* dimarts, 12 de desembre de 2023 13:17
*Para:* Abel Pau <a....@creaf.uab.cat>; gdal-dev@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.
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
