I don't understand how this works. What if not centered in 0?

I don't understand how this works. What if not centered in 0?

The "center" of the map is the longitude and latitude indicated in -J.

If not entered then you do standard stuff like -R-600/200/-100/300+uk etc.

I don't know how to unlike my own comment...
I agree with @meghanrjones and will make that change in the docs.

I find this option confuse. Many projections do not use a latitude parameter (that is lat_0 = 0). So this means the rectangle will always have to be around the equator, no?

In fact I had a similar idea for the Julia wrapper but always gave up because I could never remember what -Rx was supposed to mean.

I find this option confuse. Many projections do not use a latitude parameter (that is lat_0 = 0). So this means the rectangle will always have to be around the equator, no?

In fact I had a similar idea for the Julia wrapper but always gave up because I could never remember what -Rx was supposed to mean.

I think even Mercator optionally takes that latitude, but it is not universal and for many it would mean Equator. The key use of this is to make lots of maps that all are centered on various locations and have the same dimensions - one would never want to use the Eckert project for this, for example (well, maybe your new Lester would). I do this all the time and this is just a logical simplification. Way more useful than the one we added for Kurt Feigl in 2016...

BTW @meghanrjones I switched the syntax and docs to your suggestion.

The key use of this is to make lots of maps that all are centered on various locations and have the same dimensions

Ah, a bash-lovers short circuit thing ... still one not working for Mercator (and cousins) in other then around the equator.

In other words there is room for improvement in our -J settings.

improvement in our -J settings

But not to please this option (ofc there is the proj4 string syntax, etc)

improvement in our -J settings

But not to please this option (ofc there is the proj4 string syntax, etc)

yes. I am waiting for Leo to respond to my change of refactoring before we schedule a chat focused on C refactoring things, such as pro, but no word yet - busy times. I also do not want to have that chat and then have 3 weeks of holiday delay any actual action. So maybe we have that chat in early January anyway.

Sorry but I still think this is not a good solution. If I got it right this is for when one want to make a map with a certain Cartesian width centered in some point. As implemented the center point is the projection center that, as mentioned above, for may projections lies on the equator only. So this option works only sometimes. And why would we force the map center to be on the projection center?

A better way would be to set -Rx[/y]/lon0/lat0+c[u] where user explicitly sets the map center and x is the map width, in km by default but changeable with units

Perhaps we can consider a +clon0/lat0 modifier to set a specific center projection point, with the default being the projection origin. That way, the users of projections that has a specific point (azimuthal for instance) can accept the default (as currently encoded) while others can use +c.

Better to leave the +c clean as we do with +r

-Rx[/y]+c => use projection center
-Rx[/y]/lon0/lat0+c => Set the map center

Requiring +c breaks backwards compatibility for the cases that have been used forever like this. Also, we do not have modifiers that take its arguments before the modifier, but I understand what you mean "+c means the last two args are center coordinates, not projected distances". I will think more about this. We do not want backwards incompatibilities in -R.

I'm using +c like we use +r. Why would it break compatibility?

Sorry, it would not. No coffee yet, no breakfast, you expecting me to engage in a technical conversation this early?

Hawaiian chickens are well awaken already and for quite some time now.

Here is the backwards issue I was thinking of. This currently works great (i.e., before we even merged this branch:

gmt pscoast -R-300/300/-300/300+un -JA204/21/14c -Glightgray -B -pdf map

(This is the long-version of the first plot in the test above). As you see, it requires no +c to set the central point to 204/21 since that is set via -J. This has worked for a decade at least, so we do not want toads a +c as a requirement for it to continue to work. So the +c has to be optional I think. I do not think

gmt pscoast -R300/204/21+un+c -JA204/21/14c -Glightgray -B -pdf map

would be a useful syntax as now the savings are gone. I also think the azimuthal projections are the ones where this is most useful but of course that is user-dependent. Hence, I think +c needs to be +clon0/lat0 with default to the projection center. This may be at Equator for many/most projections. So, a Mercator version of the above might be

gmt pscoast -R300+un+c204/21 -JM14c -Glightgray -B -pdf map

I think your suggestion

-Rhalfwidth[/halfheight][/lon0/lat0+c]+uunit

could work but I do think passing those arguments to +c is a better implementation in line with most situations in GMT.

So in summary, the shortcut was introduced because making such a square/rectangle centered on the azimuthal touch point can so easily be done this way, but I agree that for non-azimuthal and non-conic projections there would have to be more. We could accommodate this for those projections via optional latitudes, i.e.

-JH[lon0[/lat0]/]width

where the lat0 has no affect on the projection but lets us compute the (x,y) projected units of the center point and now we can do relative measurements from there. It is mostly those global projections plus some cylindrical that would need this info and then that is the logical way to set the projection center (in -J rather than in -R).

So the +c has to be optional I think. I do not think
gmt pscoast -R300/204/21+un+c -JA204/21/14c -Glightgray -B -pdf map
would be a useful syntax as now the savings are gone.

but it would not be -R300/204/21+un+c, only -R300+un+c because the center is here set by -JA204/21/14c

-JH[lon0[/lat0]/]width

That is the part that I'm against. We should not change the -J syntax (with no parallel in proj4) just to please -R

OK, so we would know for -JA,S,G etc that we already have a valid default point so -R300+un+c is understandable. That means the syntax is actually [/lon0/lat0]+c then? What do you do with

-R-300/200/-150/75+un -JA204/21/14c

then? Do we really want to parse that and somehow figure out that -150/75 can't be lon/lat since the halfwidth is negative, etc, etc? I can imagine cases where there is just no way to know.

-300/200/-150/75+un

without +c the -150/75 would not be the map center, no? I guess there will be many cases where a requested rectangle cannot be obtained

Well, the point is that the above (-R-300/200/-150/75+un) works because there is a map center at (0,0) set via -J. Requiring +c means we break backwards compatibility in this case, hence my desire to keep +c optional.
I have not checked, but is there no way in proj to specify a projection center, say, for Mercator? I.e., a latitude? Seems like that is totally a -J thing since a projection origin is always somewhere.

(Speaking of -R overhaul: #3099)