diff options
Diffstat (limited to 'docs/source/community/rfc')
| -rw-r--r-- | docs/source/community/rfc/rfc-2.rst | 12 | ||||
| -rw-r--r-- | docs/source/community/rfc/rfc-3.rst | 4 | ||||
| -rw-r--r-- | docs/source/community/rfc/rfc-4.rst | 10 | ||||
| -rw-r--r-- | docs/source/community/rfc/rfc-5.rst | 6 |
4 files changed, 16 insertions, 16 deletions
diff --git a/docs/source/community/rfc/rfc-2.rst b/docs/source/community/rfc/rfc-2.rst index 4cea339d..7da1bc4f 100644 --- a/docs/source/community/rfc/rfc-2.rst +++ b/docs/source/community/rfc/rfc-2.rst @@ -157,7 +157,7 @@ all classes, except the CoordinateOperation class that point to CRS for sourceCRS and targetCRS members, whereas DerivedCRS point to a Conversion instance (which derives from CoordinateOperation). This issue was detected in the ISO-19111 standard. The solution adopted here is to use std::weak_ptr -in the CoordinateOperation class to avoid the cycle. This design artifact is +in the CoordinateOperation class to avoid the cycle. This design artefact is transparent to users. Another important design point is that all ISO19111 objects are immutable after @@ -215,12 +215,12 @@ On the algorithmic side, a somewhat involved logic is the CoordinateOperationFactory::createOperations() in `coordinateoperation.cpp`_ that takes a pair of source and target CRS and returns a set of possible `coordinate operations`_ (either single operations like a Conversion or a -Transformation, or concatenated operations). It uses the intrinsinc structure +Transformation, or concatenated operations). It uses the intrinsic structure of those objects to create the coordinate operation pipeline. That is, if going from a ProjectedCRS to another one, by doing first the inverse conversion from the source ProjectedCRS to its base GeographicCRS, then finding the appropriate transformation(s) from this base GeographicCRS to the base -GeographicCRS of the target CRS, and then appyling the conversion from this +GeographicCRS of the target CRS, and then applying the conversion from this base GeographicCRS to the target ProjectedCRS. At each step, it queries the database to find if one or several transformations are available. The resulting coordinate operations are filtered, and sorted, with user provided hints: @@ -238,7 +238,7 @@ resulting coordinate operations are filtered, and sorted, with user provided hin compared. By default, only transformations whose area of use is fully contained in the desired area of use are selected. It is also possible to relax this test by specifying that only an intersection test must be used. - - whether `PROJ transformation grid`_ names should be susbstituted to the + - whether `PROJ transformation grid`_ names should be substituted to the official names, when a match is found in the `grid_alternatives` table of the database. Defaults to true - whether the availability of those grids should be used to filter and sort @@ -636,7 +636,7 @@ Impacted files -------------- New files (excluding makefile.am, CMakeLists.txt and other build infrastructure -artifacts): +artefacts): * include/proj/: Public installed C++ headers - `common.hpp`_: declarations of osgeo::proj::common namespace. @@ -853,7 +853,7 @@ Doxygen. .. _`Spaghetti inheritance diagram`: http://even.rouault.free.fr/proj_cpp_api/html/inherits.html A basic integration of the Doxygen XML output into the general PROJ -documentation (using reStructuredText format) has been done with the the +documentation (using reStructuredText format) has been done with the Sphinx extension `Breathe`_, producing: * `One section with the C++ API`_ diff --git a/docs/source/community/rfc/rfc-3.rst b/docs/source/community/rfc/rfc-3.rst index ae4bff95..439f22d1 100644 --- a/docs/source/community/rfc/rfc-3.rst +++ b/docs/source/community/rfc/rfc-3.rst @@ -50,7 +50,7 @@ Background PROJ has traditionally been written in C89. Until recently, no formal requirements of e.g. build systems has been defined and formally accepted by -the project. :ref:RFC2 <rfc2>` formally introduces dependencies on C++11 and +the project. :ref:`RFC2 <rfc2>` formally introduces dependencies on C++11 and SQLite 3.7. In this RFC a rolling update of version or standard requirements is described. @@ -94,7 +94,7 @@ PROJ uses C89 and C++11. For C, that means that the used standard is three iterations behind the most recent standard. C++ is two iterations behind. Following the rules in this RFC the required C standard used in PROJ is at allowed to be two iterations behind the most recent standard. That means that a -change to C99 is possible, as long as the PROJ PSC aknowledges such a change. +change to C99 is possible, as long as the PROJ PSC acknowledges such a change. When a new standard for either C or C++ is released PROJ should consider changing its requirement to the next standard in the line. For C++ that means a diff --git a/docs/source/community/rfc/rfc-4.rst b/docs/source/community/rfc/rfc-4.rst index 738dd4bb..9673c898 100644 --- a/docs/source/community/rfc/rfc-4.rst +++ b/docs/source/community/rfc/rfc-4.rst @@ -89,7 +89,7 @@ can build with rather ancient libcurl for similar functionality, we can aim for libcurl >= 7.29.0 (as being available in RHEL 7). An alternate pluggable network interface can also be set by the user in case -suppot for libcurl was not built in, or if for the desired context of use, the +support for libcurl was not built in, or if for the desired context of use, the user wishes to provide the network implementation (a typical use case could be QGIS that would use its QT-based networking facilities to solve issues with SSL, proxy, authentication, etc.) @@ -223,7 +223,7 @@ to limit the number of HTTP GET requests and minimize latency caused by network access. This is very similar to the behavior of the GDAL `/vsicurl/ <https://gdal.org/user/virtual_file_systems.html#vsicurl-http-https-ftp-files-random-access>`_ I/O layer. The plan is to mostly copy GDAL's vsicurl implementation inside PROJ, with -needed adjustmeents and proper namespacing of it. +needed adjustments and proper namespacing of it. A retry strategy (typically a delay with an exponential back-off and some random jitter) will be added to account for intermittent network or server-side failure. @@ -403,7 +403,7 @@ and ${LOCALAPPDATA} on Windows builds. Exact details to be sorted out, but https://github.com/ActiveState/appdirs/blob/a54ea98feed0a7593475b94de3a359e9e1fe8fdb/appdirs.py#L45-L97 can be a good reference. -As this database might be accesse by several threads or processes at the same +As this database might be accessed by several threads or processes at the same time, the code accessing to it will carefully honour SQLite3 errors regarding to locks, to do appropriate retries if another thread/process is currently locking the database. Accesses requiring a modification of the database will @@ -602,7 +602,7 @@ Weak points: * Multi-samples variables are located in different sections of the files (correspond to TIFF PlanarConfiguration = Separate) -* No natural way of having hiearchical / multigrids. They must be encoded as +* No natural way of having hierarchical / multigrids. They must be encoded as separate variables * georeferencing in netCDF is somewhat less standardized than TIFF/GeoTIFF. @@ -704,7 +704,7 @@ document. Tooling +++++++ -A script will be deveoped to accept a list of individual grids to combine +A script will be developed to accept a list of individual grids to combine together into a single file. A ntv2_to_gtiff.py convenience script will be created to convert NTv2 grids, diff --git a/docs/source/community/rfc/rfc-5.rst b/docs/source/community/rfc/rfc-5.rst index 6e9bf5b7..44811d58 100644 --- a/docs/source/community/rfc/rfc-5.rst +++ b/docs/source/community/rfc/rfc-5.rst @@ -22,7 +22,7 @@ as https://github.com/OSGeo/proj-datumgrid converted in GeoTIFF files. In the current state, we could have a somewhat inconsistency between users relying on the proj-datumgrid, proj-datumgrid-[world,northamerica,oceania,europe] packages of mostly NTv2 and GTX files, and what is shipped through the CDN. Maintaining -two repositories is also a maintaince burden in the long term. +two repositories is also a maintenance burden in the long term. It is thus desirable to have a single source of truth, and we propose it to be based on the GeoTIFF grids. @@ -44,14 +44,14 @@ Summary of work planned by this RFC and related decisions - Each file will be named according to the following pattern ``${agency_name}_${filename}[.ext]``. For example fr_ign_ntf_r93.tif This convention should allow packagers, if the need arise, to be able to - split the monolothic package in smaller ones, based on criterion related to + split the monolithic package in smaller ones, based on criterion related to the country. The agency name is the one you can see from the directory names at https://github.com/OSGeo/PROJ-data/. ``${agency_name}`` itself is structure like ``${two_letter_country_code_of_agency_nationality}_${some_abbreviation}`` (with the exception of eur_nkg, for the Nordic Geodetic Commission which - isn't affiliated to a single country but to some european countries, and + isn't affiliated to a single country but to some European countries, and follows the general scheme) - https://github.com/OSGeo/proj-datumgrid and related packages will only be |