Merge RFC4

[rouault]

This is the PR merging RFC4 to master.

@kbevers Do you prefer this squashed or merged ?

[kbevers]

This is the PR merging RFC4 to master.

Hooray! Well done, Even. You have pulled of an impressive piece of work.

@kbevers Do you prefer this squashed or merged ?

Ideally I would like this to be divided into commits corresponding roughly to the pull requests you've done. That may be a rather complicated git rebase effort. If it is too difficult to do I think it is best to just merge as is. One massive squashed commit would make it difficult to find the root cause of a bug using git bisect. There will be other downsides as well.

[rouault]

If it is too difficult to do

I think it indeed goes beyond my git capabilities. Especially since there was a merge from master to rfc4_dev at some point, so I think the rebasing model would completely break. I'll go to the regular merge then.

[kbevers]

I just tried to squash some related commits in an interactive rebase. It is doable but not without effort. Some conflicts will arise. After a more careful look at the commits I think most of them are fine as they are. Some of the commits adressing reviews could be squashed into their original commits to provide a better commit history, I would think that is fairly easy to do.

[rouault]

I would think that is fairly easy to do.

Well, I just tried and miserably failed. I've checkout rfc4_dev and do a git rebase -i master, then I tried to move commit "xyzgridshift.rst: fix typo" just after "Add a +proj=xyzgridshift method to perform geocentric translation" to squash them together, but it fails when applying the very first commit of rfc4_dev.

[kbevers]

Well, I just tried and miserably failed

okay, bummer. I don't know if it matters but I tried with git rebase -i 41ff947~ on rfc4_dev and squashed all the commits starting with "Network:". It resulted in one merge conflict that at first glance didn't look to difficult to fix. It would probably still be difficult to merge into master without to many conflicts.

[rouault]

git rebase -i 41ff947~

OK, that's a bit better indeed, but when just applying that and validating, I get conflicts exactly at the points where I got conflict when merging master back to rfc4_dev a few days ago. I'm afraid solving them could result in a history where some points wouldn't be buildable. I think mixiing git merge + git rebase is a big no no in git practices.

I've also considered to try to redo a clean history by manual merging, but the effort+risk of forgetting something is discouraging

I think the squash everything button of github might be the best option.

[kbevers]

I'm afraid solving them could result in a history where some points wouldn't be buildable

Yes, each commit should preferable the repo in a buildable state.

I think the squash everything button of github might be the best option.

All things considered I think you are right. It would be great if you could update the commit message, giving a big picture overview of whats been done instead of just the list of commit headers GitHub usually puts in as the commit message when squashing

[rouault]

It would be great if you could update the commit message, giving a big picture overview of whats been done instead of just the list of commit headers GitHub usually puts in as the commit message when squashing

sure. What do think of the following ?

This commit is the result of the squashing of rfc4_dev branch in a single
commit. It implements mostly RFC 4 related work.

* Grid handling:
  - remove obsolete and presumably unfinished implementation of grid catalog functionality
  - all grid functionality is in grids.cpp/.hpp
  - vertical and horizontal grid shift: rework to no longer load whole grid into memory
  - remove hgrids and vgrids member from PJ structure, and store them in hgridshift/vgridshift/deformation structures
  - build systems: add optional libtiff dependency. Must be explicitly disabled if not desired
  - add support for horizontal and vertical grids in GeoTIFF, if libtiff is available
  - add GenericShiftGridSet and GenericShiftGrid classes, relying on TIFF grids, that can be used for generic purpose grid-based adjustment
  - add a +proj=xyzgridshift method to perform geocentric translation by grid. Used for French NTF to RGF93 transformation using gr3df97a.tif grid
  - deformation: add support for +grids= for GeoTIFF grids
  - horizontal grid shift: fix failures on points slightly outside a subgrid (fixes #209)

* File management:
  - add a filemanager.cpp/.hpp to deal with file related work
  - test for legacy proj_api.h fileapi
  - proj.h: add proj_context_set_fileapi() and proj_context_set_sqlite3_vfs_name() (fixes #866)
  - add capability to read resource files from the user writable directory

* Network access:
  - build systems: add optional curl dependency
  - add a curl-based default implementation for network related functionality
  - proj.h: add C API to control network functionality, and optionaly provide network callbacks
  - add data/proj.ini with default settings
  - add a SQLite3 local cache of downloaded chunks
  - add proj_is_download_needed() and proj_download_file()

* Use Win32 Unicode APIs and expect all strings to be UTF-8 (fixes #1765)
  For backward compatibility, if PROJ_LIB content is found to be not UTF-8 or
  pointing to a non existing directory, then an attempt at interpretating it
  in the ANSI page encoding is done.
  proj_context_set_search_paths() now assumes strings to be in UTF-8, and
  functions returning paths will also return values in UTF-8.

[kbevers]

I think that is great @rouault. Feel free to merge :)

[rouault]

Done !!!! :-)