Even Rouault via gdal-dev <gdal-dev@lists.osgeo.org> writes: > Cf https://github.com/OSGeo/gdal/pull/8558: "GPX: add a CREATOR > dataset creation option"
Thanks; long pause on my part to let this settle in my head. > It will be of course up to the application / application user to set it. I guess the really interesting question is what the appetite is for using that, in terms of each user going to the effort to add a configure test and ifdef. My impression is that people looking at gpx files might care, but most creator programs probably do not. So if this is merged, I don't really expect to see users adopt it. > I've considered a global GDALSetDefaultCreatorApplication() (could be > similar to CPLHTTPSetDefaultUserAgent(): > https://gdal.org/doxygen/cpl__http_8h.html#ae83c06d51089bb340ed0b98a6ed8d01d) > so that an application could set a default for all formats that write > a creator application, but this leads to introducing potential options > to express "totally replace the GDAL version" vs "add my name in > addition to the GDAL version", That consideration seems to apply to GPX, too, and the PR chooses "replace". I would say we should not be afraid of arbitrary because what we have now is arbitrary. I lean to "include this string and the GDAL version both". I don't see why we should support "replace" which leads to the file not having the GDAL version. Hiding seems useful only for some kind of stealth operation, to hide the version in use and hence the time, or something that could be leveraged for an attack. Or for vanity and trying not give credit. I don't think either need supporting; paranoid people can postprocess or roll their own, and people avoiding crediting GDAL shouldn't be helped. > or "put application/version number only when required by the format" > vs "put application/version wherever the format could allow it, but > only if there's a standardized location to do so" vs "put > application/version wherever the format could allow, I lean to "place it in the format if it is reasonable to do so", and let the judgements happen. That's somewhere between the last two. I don't see why we should support "only if required". We don't currently have an option to "hide that this was created by GDAL". > potentially it in a custom metadata item if there's no standardized > location". e.g in netCDF, we have a custom attribute GDAL = "GDAL > x.y.z, released YYYY/MM/DD" (it would not be appropriate to put the > identification of the larger application in it, given the name of the > attribute and the fact that GDAL itself parses it on reading to > determine the bottom-up vs top-up orientaiton). It seems easy enough to skip this format on the first pass, doing no harm compared to how things are now be open to a future PR that adds creator= with the string that would have been written if there weren't already a machine-readable GDAL code point > So I've not pursued this given all those dilemmas :-) I think that choosing to put in both higher-layer name and gdal version, and making arbitrary reasonable choices is a significant improvement over where we are. I do not expect people to really want to have the kind of optional control above. All sorts of programs in all sorts of formats emit this kind of label and they seem to get used by people looking at random files they have, that they don't really know where they came from, to help figure that out, and otherwise it isn't that important. I don't hear complaints about "I wish I could find tune this". I know I said I didn't expect users to adopt the GPX creator API call, but I am more optimistic about a general one, since it gives more benefit for the same work. So I'm kind of -1 on just adding this for GPX, as it adds API complexity without broadly addressing the goal. I'm +1 on renaming the API to be general instead of GPX, only having code for GPX for now, with the output being something like "%s, GDAL %s", [arg passed to call], GDALVersionInfo("RELEASE_NAME") (I should note that I have zero commercial interest in this; I'm just here relaying a concern from the GPX community about creator in GPX, and the rest is just my software/format architecture comments.) _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
