-
Notifications
You must be signed in to change notification settings - Fork 353
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
A smarter selection of the region when using -R...r with non-cartesian projections #3099
Comments
This is a great suggestion, and I will vouch for it. My experience is the same; |
I find it way easier to specify the region in, say, km relative to the desired projection center, e.g.,
Isn't that a simpler mechanism?
|
@PaulWessel I must admit I haven't thought of this possibility. Let me toy around with it a bit and I'll report back. |
Paul, if I would like to make a map created with
to be rectangular, what would be the best way? Is it possible with the method you mentioned above? What about having an option to say to GMT, "make the map with given Sorry to hijack the thread @KristofKoch (hope it's OK). I think we want the same thing. |
I found the recommendation by @PaulWessel to specify the distances from projection center quite useful but it doesn't always fit my bill if I have to fit some fixes in the extreme corners onto the plot. Then it is back to trial and error. There the idea of @anbj comes in very handy (thank you for your input) and is even simpler than my ideas presented in the original post. Is there a way of tweaking the projection parameters to get a plot with specified dimensions when using Pauls idea? Width is no problem but height is. Say I want to fit a map on a page of DIN A4 paper (210 mm x 297 mm). I was able to achieve this with the current -R...r behavior by calculating the upper right coordinate. Am I missing something? Additionally I found the
|
Any news about this? |
This issue has been automatically marked as stale because it has not had activity in the last 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions. |
Ping? |
This issue has been automatically marked as stale because it has not had activity in the last 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions. |
This is a better example of what I meant, this time made with professional software. Enter normal
|
Ping |
Following up from #6474 (comment), do you think an example of that mapproject use-case in the new gmt-examples site would be sufficient for this issue? |
For me, yes, to a very large degree. But I can't answer on behalf of @KristofKoch! |
Just for reference; what I wanted was implemented in #6669. |
@KristofKoch and @anbj , please revisit and see if #7657 provides a workable solution to some of these. |
When using gridded data in non-cartesian projections with rectangular borders I run into some problems when selecting the region of interest. The current mechanism is to specify lower left and upper right corner of the region of interest when using
-R...r
. This creates some difficulties in higher latitudes when using it with projections like Lambert conic conformal-JL
as illustrated in this crude mockup:Explanation:
-R...r
-JL
with the blue dashed lines representing the center of the projectionselect
/grdimage
/etcProblems:
Feature request, open for debate:
-R
withoutr
where one specifies the northern and southern most latitudes and can use one of the following longitude specifications:-J
, proposed-R...rm
for mid (see example 1 below)-R...rx
for max (see example 2 below)-R...rn
for min (see example 3 below)select
/grdimage
/etc to cover the red areas.Example 1:
The longitudes are referenced to the latitude of the projection center.
Example 2:
The longitudes are the min longitudes to be present on the plot.
Example 3:
The longitudes are the max longitudes displayed on the longest line of latitude.
In all cases the parameters for the "expanded" projection are calculated in the background.
While making this feature request it came to my mind that this could be seen as two different requests. One for the different ways to define the region and one for the calculation of the expanded projection parameters in the background. Please advise if I should split them.
The text was updated successfully, but these errors were encountered: