Rename OBS-API to 4D-API

[busstoptaktik]

To talk about something, it needs a name, so the "new geodetic API" got the name OBS-API, since it was based on the OBServation data type.

As most of the problems the OBS data type was intended to solve has now found other, and more elegant, solutions, the COORDinate data type is really the workhorse of the OBS API. So we may very well discourage the use of PJ_OBS, pj_fwdobs, pj_invobs, etc, even before it appears in an official release.

As it is probably better anyway to have an API name that relates to the core functionality exposed by the API, rather than the data type it happens to leverage, I propose we change the name of the API to the PROJ.4 4D-API.

We can leave the header name as is, or change it to proj4d.h if that is better (I think @rouault once mentioned a SGI 1990s system header with the proj.h-name, so changing to proj4d.h would make it easier for the SGI nostalgia crowd, to run PROJ.4 on their aging Octanes :-) ).

proj_obs, proj_trans_obs, proj_transform_obs, and PJ_OBS should go from the surface of the API. They cannot go (immediately) from the library, though, as they are used as workhorses for the COORD style functions.

Eventually ridding PROJ.4 of the PJ_OBS data type would, however, offer a slight speed advantage.

[kbevers]

@busstoptaktik I think you're the only one that have actively been using the name "obs api", so this is probably not a very big deal. I simply regard the API in proj.h as the API of PROJ.4 - everything before that is old news and deprecated in my eyes (and the new docs I am working on).

We can leave the header name as is, or change it to proj4d.h if that is better

I'd prefer to keep it as is: It's simple and matches the namespace of the functions in the API.

proj_obs, proj_trans_obs, proj_transform_obs, and PJ_OBS should go from the surface of the API. They cannot go (immediately) from the library, ...

+1

... though as they are used as workhorses for the COORD style functions.

That shouldn't be that difficult to change, no?

Eventually ridding PROJ.4 of the PJ_OBS data type would, however, offer a slight speed advantage.

That would be nice. Any idea how much? :-)

Are you planning on changing the name of pj_obs_api.c as part of this?

[busstoptaktik]

That would be nice. Any idea how much?

Probably not much. It's 3 small improvement steps:

• Half the amount of memory to sail up and down on the stack,
• Elimination one level of chained function calls, and
• Perhaps some slightly reduced combinatorics in the selector logic

Are you planning on changing the name of pj_obs_api.c as part of this?

I intend to change it to pj_4d_api.c or perhaps better proj_4d_api.c.
proj_api.c would not fly, since it would hint at a relation to proj_api.h.

One might argue that the same confusion could be expected regarding proj.c/proj.h, but I really don't think anyone would expect to find a header file declaring an interface to a command line program.

On the other hand, I liked the IRIX OS and the SGI 1990s Indy, Indigo, Octane, etc hardware, and wouldn't mind seeing a bit of PROJ.4 retrocomputing taking place, which would be in favour of proj_4d_api.h :-)

[busstoptaktik]

(Apparently I hit "Close and comment", rather than "Comment" on this. It's not done yet :-)