Next libgeotiff release ?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Next libgeotiff release ?

Even Rouault-2
Hi,

Now that PROJ 6.0 has been released, we could release libgeotiff master that
removes the CSV dependency for the EPSG database and requires PROJ 6.0.

While being mostly compatible with previous versions, there are a few
'technical' symbols that have been removed:
- cpl_serv.h: all CSV related symbols, but I guess those were only used
internally by libgeotiff
- geo_normalize.h: GTIFDeaccessCSV and SetCSVFilenameHook. Those ones affect
external users.

I thought for now about numbering this next libgeotiff version 1.5.0, but we
might also call it 2.0. Thoughts ?

Another thing I should mention is that within OGC, a geotiff 1.1 specification
is in the works. Nothing spectacular to expect from that revision of the
original 1995 spec - that's a feature -, but a few updates/fixes there & there
(most notable changes are related to the vertical dimension).
Current state of the work can be seen at:
https://github.com/opengeospatial/geotiff/blob/master/geotiff_standard.pdf

Once adopted, libgeotiff should/could be updated to take into account the
changes/additions (changes will be needed in GDAL as well). I don't think we
should wait for those changes to be implemented to release the next libgeotiff
version (there's no funding for that work currently)

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
Geotiff mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geotiff
Reply | Threaded
Open this post in threaded view
|

Re: Next libgeotiff release ?

Howard Butler-3


On Mon, Mar 11, 2019 at 8:22 AM Even Rouault <[hidden email]> wrote:
Hi,

Now that PROJ 6.0 has been released, we could release libgeotiff master that
removes the CSV dependency for the EPSG database and requires PROJ 6.0.

While being mostly compatible with previous versions, there are a few
'technical' symbols that have been removed:
- cpl_serv.h: all CSV related symbols, but I guess those were only used
internally by libgeotiff
- geo_normalize.h: GTIFDeaccessCSV and SetCSVFilenameHook. Those ones affect
external users.

I thought for now about numbering this next libgeotiff version 1.5.0, but we
might also call it 2.0. Thoughts ?

Another thing I should mention is that within OGC, a geotiff 1.1 specification
is in the works. Nothing spectacular to expect from that revision of the
original 1995 spec - that's a feature -, but a few updates/fixes there & there
(most notable changes are related to the vertical dimension).
Current state of the work can be seen at:
https://github.com/opengeospatial/geotiff/blob/master/geotiff_standard.pdf

Once adopted, libgeotiff should/could be updated to take into account the
changes/additions (changes will be needed in GDAL as well). I don't think we
should wait for those changes to be implemented to release the next libgeotiff
version (there's no funding for that work currently)

I too think we should call it 1.5.0 and issue a 2.0 once and if any changes roll out of the OGC efforts. Specifically, I think that your proposal for formalization of a WKT key is something we would find very useful in lidar land. https://github.com/opengeospatial/geotiff/issues/56

Did GTIFDeaccessCSV and SetCSVFilenameHook get removed or no-op'd? I suppose I'd vote for the latter. Removing them is going to sprinkle #defines in code for not much gain, right?

Howard
 

_______________________________________________
Geotiff mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geotiff
Reply | Threaded
Open this post in threaded view
|

Re: Next libgeotiff release ?

Even Rouault-2
Howard,

> I too think we should call it 1.5.0 and issue a 2.0 once and if any changes
> roll out of the OGC efforts.

OK

> Specifically, I think that your proposal for
> formalization of a WKT key is something we would find very useful in lidar
> land. https://github.com/opengeospatial/geotiff/issues/56

That's certainly not in the scope of the current GeoTIFF 1.1 effort. This is a
major breaking change (and simplification !). Other stakeholders haven't yet
reacted on this.

>
> Did GTIFDeaccessCSV and SetCSVFilenameHook get removed or no-op'd? I
> suppose I'd vote for the latter. Removing them is going to sprinkle
> #defines in code for not much gain, right?

Removed, since once I managed to get to the point where "grep -ri CSV"
returned a completely empty set, I was sure of having done the job :-) But,
yes I can re-add them as no-op.

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
Geotiff mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geotiff