NZ traverses the 180 degree meridian (main islands W of 180, the Chatham Is E of 180).

The NZ 'official' projection is NZTM2000, which to all intents is just a TM projection with specific parameters (will attach figs if I can)

I have maps with some layers that are in NZTM2000 projection & others that are in the equiv TM projection (ie. come from different sources). Map itself is equiv TM projection since I used a drawing in the equiv TM proj to create the map.

Map displayed OK in R6.5, but now with 7.1 the layers that are in NZTM2000 display the Chatham Is at some "nonsensical" location (1.3m km SW of the main islands)

Is this a "bug" or a "feature"?

David

FWIW, all the drawing layers display fine if displayed as a drawing, or in a map which has only just NZTM2000 or just equiv TM layers.

Attachments:
Eqiv TM projection.gif
NZTM projection.gif

That's a goody. Wherever the poor Chathams have gone, I hope it's somewhere a bit less rainy. But still with lots of crayfish and cod.

A tiny niggle, which doesn't matter: by NZTM2000 I think you mean just NZTM, which is in terms of NZGD2000.

And I don't think it should matter that NZTM uses NZGD2000 for its datum, while "equivalent TM" is using WGS84. The two datums are nearly synonymous. FWIW, all the drawing layers display fine if displayed as a drawing, or in a map which has only just NZTM2000 or just equiv TM layers. Are you able to attach a "cross product" of this arrangement, i.e. a map in each projection, each of them containing drawings in each projection?

Tim

Ps. My guess is that at some point some of the data has been subjected to an Assign Projection when a Change Projection was required, or vice versa.

Tim

"... I think you mean just NZTM ...". Apologies, you are correct.

I later realised that the "equivalent TM" projection came about because the drawings I imported had ESRI generated .prj files that Manifold obviously does not fully recognise - just picks up the TM part and the parameters. Since the "equiv TM" projection it comes up with is indeed "fully equivalent", then I had more to do than re-project to NZTM.

I now discover that if I take an NZTM map, duplicate it and change the projection of the duplicate to the equivalent TM projection (except with NZGD2000 datum), then the two drawings exactly overlay (all parts in the correct location - including the crayfish on Chatham Is).

Then change (only) the datum of the duplicate to WGS84:

If the drawing is viewed by itself, the parts W of 180 are correctly located (judging by the lat & long reported in the status bar), parts E of 180 (ie Chatham Is) are off in space; ie. c 1.3m km mis-located.

If now overlay original & duplicate in a map then:

- If map is created from the duplicate (ie. Map is equiv TM), the dwgs exactly overlay (see Fig 1 attached - NB red = thin line overlaying thick dashed blue line) ... BOTH show Chatham Is grossly mis-located (and distorted). But viewing the NZTM layer as a drwg by itself at the same time continues to show Chatham Is correctly. Note that the behaviour is different than it was when the equiv TM was assigned during import!

- If map created from the original (ie. Map is NZTM), duplicate displays as a nonsensical mess (per Fig 2 attached - blue = NZTM which is OK; red = equiv TM mess: Note that these are the same same layers as in Fig 1. ie. both maps co-existing at the same time with both layers common to the two maps).

I am tending to the "bug" theory?

David

Attachments:
Fig 1 - Equiv TM map w. dashed blue NZTM & red equiv TM (CI 1.3m km off map).gif
Fig 2 - NZTM map w. blue NZTM & red equiv TM.gif

David,

It's getting late (are you here too? time for bedbyes), and I've been obsessed with something else. I may be better able to process this in the morning, it's very clearly set out in words but everything would be clearer (or not) if I could push the superstring-theory-is-true button myself (figure 2), following your description. Can you post a map?--Tim

I'm not sure if you are confusing changing a component's projection with assigning a component's projection. Sorry if that's not the case, and please provide example data (either data files or a Manifold map) and hopefully we can help you out.

https://github.com/mdsumner

OK, here goes:

Attached map file contains 4 drwg layers & 4 maps.

To keep size down I retained only 3 Wellington area TAs (Wgtn) and the Chatham Is (CI) in the map. Crown copyright applies etc .....

The 4 drwgs are:

- original pasted in from another map file was in "Equiv TM, but with NZGD2000 datum".

Remaining 3 drwgs were all produced by duplicating off the "original"

- "NZTM" drwg had projection of the duplicate CHANGED to NZTM - "Equiv TM (assigned)" had the datum of the duplicate ASSIGNED to WGS84 - "Equiv TM (changed)" had the datum of the duplicate CHANGED to WGS84

All DRAWINGS except "Equiv TM (changed)" display correctly when viewed as a drawing. "Equiv TM (changed)" displays CI distorted and ~1.3m km from Wgtn.

Re 4 MAPS:

For convenience, I have saved Views (Local, to see Wgtn at reasonable scale, and Full Map, to see all). Be aware that "Map_nztm" takes over one minute to display Full Map on a reasonably meaty laptop (T7400 CPU, 2GB Ram). Could take a while longer on lesser hardware.

Have also added labels to one map, since in cases, Wgtn only displays as a tiny dot at "Full map view" (tiny dot under centre "n" of "Wellington" on full map view).

I want bother describing the map displays in detail - can see in the map file.

Briefly: Similar results to what I described previously.

- Map_equiv_TM (changed): The layers fully overlay, with CI out in space (both layers). - Map_equiv_TM (assigned): NZTM overlays W of 180, but CI out in space (only NZTM layer - equiv_TM displays CI correctly) - Map_nztm: same mess as in my previous post. - Map_tm_NZGD2000: two layers exactly overlay (CI correctly located), TM_(assigned) layer has CI out in space.

Basically the TM (assigned) case behaves the same as when TM was assigned during import (hence the difference I previously noted between imported drawing and equiv TM applied within Manifold - obvious in hindsight)

FWIW my take is that in THIS instance assigned & changed should produce effectively the same result, since all projections are near identical. BUT, if want a drwg (correctly) projected in say NZMG to be converted to say NZTM, then would need to CHANGE the projection to NZTM.

Regardless, map display is faulty in both cases. Hopefully not a "feature"!

David

Attachments:
Projection traversing 180 deg meridian.map

Cool David thanks. Back soon (if I can think of anything to say). You're not near L'Affare I suppose?

### OT ###

Work from home 10min NW of CBD, but L'Affare (or similar local) sounds a good idea sometime. Perhaps a Lower NI "User Meeting".

Have a 2wk trip abroad next week & up to my proverbial preparing for it just now, so perhaps in a month or so.

D

I'm in Ngaio, which I time at 6mn.

Close! Next suburb north, +4min is about right. Will have to arrange a coffee once I get back. David

FWIW my take is that in THIS instance assigned & changed should produce effectively the same result, since all projections are near identical. BUT, if want a drwg (correctly) projected in say NZMG to be converted to say NZTM, then would need to CHANGE the projection to NZTM. I agree.

What I notice first, though, is that there is something seriously amiss even in the original data. Amiss enough to make the derived problems less surprising.

Running the mouse cursor from Wellington to the Chathams, the coordinate read-out in the status bar chirrups merrily away until east of meridian 180 E / 180 W, where it is silent.

Two broad possibilites occur (as ever). 1. The imported data is simply corrupt, Manifold is doing well to display it at all, it should be imported from a different source, or from the same source in a different way. 2. Manifold has clean forgotten how to deal with (some?) projected maps which straddle meridian 180 E/W.

I doubt that it's the latter, since it's a pretty basic thing for Manifold to get right, and also because I've seen nice maps produced by Mike Sumner which straddle 180 E/W. On the other hand, I think they were in Orthographic projection.

You said in your second post: I later realised that the "equivalent TM" projection came about because the drawings I imported had ESRI generated .prj files that Manifold obviously does not fully recognise - just picks up the TM part and the parameters. Since the "equiv TM" projection it comes up with is indeed "fully equivalent", then I had more to do than re-project to NZTM. I don't quite follow in the very last phrase. But it seems that things went sufficiently strange during the initial import that it might be wise to try again from scratch. But something tells me (let me see, could it be your thoroughness?) that you might have tried that already.

Looking at Wgtn_tm_NZGD2000 Table, there's another obvious problem. Well, three. One of the problems I couldn't quite see see without resizing columns, and resizing columns seems to have hung Manifold for a minute or too so far--it didn't even like scrolling across the table, it was warning me and I should have listened--that being the second problem. The third problem is that for the Chathams data, Latitude (I) and Longitude (I) are empty, blank.

If I were now to take a punt, I'd say the mainland data and the Chathams data were in different projections in ESRI (the Chathams do have their own, don't they), but they were exported from ArcXYZ together, and wound up sharing a .prj file, which made perfect sense for the mainland but none whatsoever for the Chathams.

If that were right then the solution would be to go back to the ESRI source of this data and separate the Chathams stuff from the mainland stuff before exporting, and keep it that way until it's inside Manifold.

I could be ±180° wrong about all of that though.

re CI vs mainland. Actually, they do come from different maps, but I do not think that is the problem.

Open a new (clean) instance of Manifold

Create > Drawing Assign NZTM projection Insert two points Change coordinates of one to something W of 180 (say around Wgtn) Change coordinates of the other to something E of 180 (say on CI)

Then view lat long. Only displays for Wgtn. Nothing shows for lat long of CI point.

ie. this is for data created in a clean copy of Manifold, with no projection changes at all.

David

Great example David.

I repeated in a slightly different way too, just to be perfectly sure that changing the coordinates of the Chathams point after its creation was not to blame (though why would it be?): ...[as above] Assign NZTM projection Zoom to 1:100 Edit | Goto... Location (latitude/longitude): Longitude 174.5, Latitude -41.3, (roughly, Wellington) Add a point in the centre of the screen Edit | Goto... Latitude/Longitude: Longitude -177.3, Latitude -43.5, (roughly, Chathams) Add a second point Then view lat long ...[as before]

The same result follows. And you have to zoom to about 1:10000000000 to see both points at once.

I agree that this should be reported David. You've gone to a hang of a lot of trouble to prove your case and it couldn't really be any clearer.

I'll re-read what Snyder has to say about TM later, to see if this has any explanation at a mathematical level. It's hardly likely: why would LINZ have chosen a TM if it couldn't straddle 180°?

It might also be worth playing around to see what other projections (if any) have issues straddling the 180 meridian; and whether TM has the same difficulty in the Northern hemisphere.

One more thought: NZTM is a bit odd because its prime meridian is almost exactly antipodal to its AOI (it uses the Greenwich meridian). It therefore has a massive false easting.

So, what happens with a TM centred on Wellington? Can it "straddle"? Tim

So, what happens with a TM centred on Wellington? Can it "straddle"? No it can't.

David's experiment repeated:

New instance of Manifold New drawing Assign projection: Transverse Mercator: Centre latitude -41.3, Centre longitude 174.50 Scale corrections (which don't matter) both 0.9996

[Drawing is positioned at the projection's origin when first opened] Zoom to 1:100 Add a point near the centre of the screen

Edit | Goto... Latitude/Longitude: Longitude -177.3, Latitude -43.5 (Chathams) Add a point near the centre of the screen

Open the drawing's table and view Latitude (I) and Longitude (I) Good for the Wellington point, empty for the Chathams

X (I) and Y (I): -0.3 and +0.3 for the Wellington point (close to the projection's centre) 944317332.3 and -1093865186.8 for the Chathams.

re: [i] Running the mouse cursor from Wellington to the Chathams, ... [/i]

I get that behaviour in all my projected maps that straddle 180, so I opt for your #2 option.

The "odd" behaviour applies to "maps" (ah la as posted), as well as PC generated point data (ie. totally different sources). I do not believe the data are corrupted, but rather that Manifold is not handling the 180 deg thing for NZTM (at least).

Note that the problems seem to arise with the conversion between NZGD2000 & WGS84. Perhaps they are too similar, differing only at nth decimal precision?

David

I'll try a test with clean data, when I get home. Pretty serious if it is the code at fault. You'll have done everyone a big favour by stepping on this if this is a bug. BTW my Manifold session still hasn't come back.

Though this is beyond me, there might be some useful info in the following document: http://www.ollivier.co.nz/projection/faq.shtm

Landsystems Ltd ... Know your land | www.landsystems.co.nz

Kim Olliver has done a great job on that page. (I hadn't seen it before.) But what DavidS has found is beyond everybody I think.

Manifold sometimes automatically rejigs longitudes > 180 to be - 360. This seems to be what's happening. Sometimes Manifold truncates longitudes > 180 back to 180 (in queries for example).

I've learnt to be wary of it, some of the things are new (since 6.0 or so) and some are just the way longlat has been considered as long as I can remember. For example, the recent fix for reprojecting image/surfaces across the dateline is just one aspect.

(I'm not sure if that's all that's going on in this thread, but that's what happened to a point I made in a longlat drawing at >180).

https://github.com/mdsumner

But Mike these are not longitudes > 180. (What does that mean? There is no such thing. I am missing something fundamental here.) At least on their face, they are latitudes between 170 and 180, and latitudes between -180 and -170.

You may well know: what is the (conventional) longitude of the meridian which is both 180 W and 180 E? How is this (supposed to be) handled mathematically?

Lastly, though of course the dateline is not a geographic entity but a political one and it cannot affect projections, please can you point me to the recent fix you mention? It sounds as if this may be quite pertinent, but I didn't register it.--Tim

Oooops sorry should've looked more carefully. I was running with my assumptions and tripped . . .

Sorry.

The fix was that images/surfaces will now reproject across the 180/-180 meridian. Before any pixels in a longlat grid would be made invisible, which is not what happens when reprojecting drawings.

It's seems fairly innocuous to simply switch the convention of 0-360 when it is convenient, but I can see why it's complicated by some situations. Manifold is inconsistent on this policy I think, since you can draw at longitudes > 180 and sometimes the objects are respected and sometimes they are automatically truncated back to 180 or have 360 subtracted.

https://github.com/mdsumner

Sorry Mike (and thanks David, below). I really needed to pull my head in there. You've got a lot of experience working around this sort of issue. I need to do some more study. (Which I'm doing.)

Here is GDAL's Frank on the issue with respect to mapserver and PROJ.4:

http://fwarmerdam.blogspot.com/2010/02/world-mapping.html

https://github.com/mdsumner

As I understand the situation, longitudes are often expressed as -180 to +180 (or 180 W to 180 E). However, they can also be expressed as 0 - 360. I have written projection routines for my own modelling software & IIRC the latter format is needed when using the TM projection equations across the dateline.

NZTM is definitely designed / intended to cover CI as well as the mainland.

David

Time to revisit this thread? David, did you report this issue, either as a bug, or a feature request?

It seems a terribly weak point of Manifold (compared to its main competition—ArcMap 9.1 has no such problem) that it can't make a sensible map which straddles the 180th meridian. My ignorant earlier responses to David's post refused to believe that Manifold could be so crippled. And in a way, though totally wrong, I was right.

How should the issue be resolved? I've been trying to make a sample map to demonstrate what isn't working, for submitting a report or request to Technical Support.

But it's making me tear my hair out. Try creating a drawing with a projection centred at say 160°W, then drawing an area of interest which extends to either side. You can't!

I love Manifold as much as anyone, but what does it do to its usefulness and its credibility, if it can't comfortably map the Pacific? (Without cunning workarounds.) It is after all the largest of the world's oceans.

Just one question matters, probably: what should we ask for? Whatever it is, Manifold can deliver it. I'm getting too lost to put it clearly, and would appreciate help.

Hi Tim,

Hasn't this been fixed in one of the updates? Though I can't find it now I was sure I had read a post by Mike Sumner about this with some attached images.

Landsystems Ltd ... Know your land | www.landsystems.co.nz

Good morning Dan.

Progress was made, due to Mike's report. This was fix number 149, appearing in 7.1.14.917 (the build David refers to in this post). It's now possible to project a raster or a drawing over the 180th meridian, using an Orthographic projection. This was a start.

But (almost?) all other projections fail.

As a matter of principle, I believe it should be both possible, and straightforward, to employ any standard projection (including azimuthals, cylindricals, pseudo-cylindricals and conics), and any official national projection for the countries within and surrounding the Pacific basin, to project data continuously over the 180th meridian.

Is that asking too much? Enough?

[Edit a bit above, and added:] Would anyone be prepared to help with testing, to determine the true scale of the problem? The first thing to do might be to define some standard maps (say two at large scale and two at small scale), with standard data, which should work. Then perhaps to break the testing up into individual-sized chunks.

Gotcha! I thought I remembered something, but I must have been half asleep. Without knowing too much about what is involved, I think your request sounds perfectly reasonable as a basic capability of any GIS.

Landsystems Ltd ... Know your land | www.landsystems.co.nz

In my experience, any time you project rasters across the Pacific you lose the "degenerate" data at longitudes > 180 (now fixed for Orthographic only). Even if you have Mercator data across the Pacific you lose it when reprojecting to Lat/Long.

It seems to me that as Manifold's functions have moved more and more to using SQL operations in the background the problem has followed the definition of the "LONGITUDE" data type - which, when data is cast to that type, truncates coordinates > 180 to 180 (rather than to their complement at -360). I made this request a while back:

I'd like to see images and surfaces in Latitude/Longitude that extend across the 180 longitude line be reprojected in a way that maintains any data at longitudes > 180. Here's an example illustrating the problem, drawings preserve data across the dateline, surfaces and images do not:

I.e. (attached map file) 1. open World2.map 2. open World2 drawing 3. zoom to NZ/Pacific region (use /View/Panes/View/ ->NZPacific) 4. select all objects in view, copy / paste as new drawing 5. Change Projection of new drawing -> OrthoGraphic CenterLon = -174, CenterLat = -30

- The data east of lon 180 (i.e. the Antarctic Peninsula) is preserved

Return to step 3. above (zoom to NZ Pacific in World2 Drawing) 6. F6, make image (default) 7. Assign projection of new image 8. Change project of new image -> OrthoGraphic CenterLon = -174, CenterLat = -30

- The data east of lon 180 is not preserved. Same goes for surfaces. (A workaround is to create a duplicate of the image, Assign its Projection to Local Offset X - 360, then copy/paste the two together and then reproject).

It seems inconsistent to me that drawings and image/surfaces behave differently.

This is the case with some SQL and other operations involving the Longitude type - although this at times will convert any longitudes >180 to 180.0 - which is another thing, and I'm not as clear about the situations. I'd certainly like to see longitudes > 180 handled as if they were -360, not pushed back to 180 - but I understand that the possibilities involved are quite diverse, and probably require some careful distinction.

It would be great if the various situations were explicitly described in the manual. And this:

Hello, assuming "Table" has data in "Column" containing numbers in the range [-180, 360] I would prefer a modification to the current behaviour:

SELECT CAST([Column] AS Longitude) FROM [Table]

Currently, this forces any values > 180 to equal 180.0, but it would be more useful if it could either:

1. Return an error, stating that the given values are not valid longitudes (as per the Data Type definition).

2. Same as (1.), but with an option argument to the CAST operator to allow longitudes greater than 180 to be converted to (lon - 360).

3. Allow CAST to accept a new Data Type called "Longitude2" - which has the following quality:

LONGITUDE2: 8 bytes A double-precision floating-point longitude value in the range [0 - 360].

BTW, the documentation currently lists the Longitude data type as:

LONGITUDE 8 bytes A double-precision floating-point *latitude* value. With these responses:

> From: Michael Sumner

> > I've tried out build 802 with the workflow described below (as in the > > original report). > > > > The same result occurs, so there seems to be no change when projecting > > lat/lon to orthographic across the dateline. > > > > ...

We have tracked the problem down to a bug in the new code that we have added. We will fix the bug. Sorry for letting it slip through.

> I would prefer a modification to the current behaviour: > > > > SELECT CAST([Column] AS Longitude) FROM [Table] > > > > Currently, this forces any values > 180 to equal 180.0, but it would > > be more useful if it could either: > > > > 1. Return an error, stating that the given values are not valid > > longitudes (as per the Data Type definition).

We agree. We have filed a request to alter the code for the CAST so it returns a NULL value.

> > 2. Same as (1.), but with an option argument to the CAST operator to > > allow longitudes greater than 180 to be converted to (lon - 360).

We agree with this as well. We think the wrapping is best done with a function.

> > 3. Allow CAST to accept a new Data Type called "Longitude2" - which > > has the following quality: > > > > LONGITUDE2 > > 8 bytes > > A double-precision floating-point longitude value in the range [0 - 360].

Given a wrapping function, this would no longer be necessary.

> > BTW, the documentation currently lists the Longitude data type as: > > > > LONGITUDE > > 8 bytes > > A double-precision floating-point *latitude* value.

We will fix this. The regime of testing is a great idea. I'd be happy to show how it's done using PROJ.4 / GDAL - which allows the specification of 0-360 longitudes using the "+over" argument to projection strings. This works even when reprojecting Mercator raster data with GDAL over the Pacific (but I'm not sure it works as comprehensively in as many cases as I'd like - due to lack of exploration, but also I'm still learning).

Attachments:
world2.map

https://github.com/mdsumner

Thanks Mike. My big bro' on this question. If there's one single thing I really want to see fixed in Manifold at present, this is it. Manifold is above this.

I haven't digested your whole post yet. (And thanks for the attachment.) But here's my first naive question:

Why is it necessary to use longitude values > 180°? I still don't get this yet.

What I most want is for 180° and -180° to be aliases, and for locations to either side to be continuous across the (arbitrary and imaginary) "join". So that:

Coords in a single line or area should happily connect say (179.9, 0) to (-179.9, 0) without flinching. These numbers should show sequentially in [Longitude (I)].

When such a drawing is projected to any coordinate system (except one broken at 180° itself), the coords sould show as connected, and the first should show to the west of the second!

I believe it is not necessary but advisable: because a component window is at some levels treated as pure X/Y Cartesian space (whether projected or not). If you "mess with that" by, for example, imposing a "real world" bound on a longitude/latitude window - and try to implement a seamless "wrap" then you end up with a forever repeating window. (Check out google maps at far out zoom. I'm not at all clear on what should happen at the poles - for well undefined reasons ;) ). Far simpler is to just treat the window space as arbitrary X/Y and allow certain operations to have meaning in certain circumstances. Data comes with endless vagaries - what for example should an elephant seal researcher do with an Argos satellite track that crosses the 180/-180 divide? The data come in the standard -180/180 convention, but how to plot it on the screen? (Just add 360 to the western longitudes, and hey presto I can make a Pacific-centric map of a seal track in any plotting program such as Excel, R, or even on the command window if I'm really bored).

Manifold is arguably inconsistent at the moment, since it should take everything that is "east of 180" in a Pacific image, clip it and stick it back in the western hemisphere. That at least would prevent the loss of data, but I still wouldn't want that as default. What would happen with a drawing of an area that crossed the dateline? Should Manifold impose a clip at 180 and split one object into two? Two branches? I say: allow operations to be performed on polar coordinates of any range and the user can decide what happens "at the boundary". It's an arbitrary meridian - we should be able to choose whether it runs from 0-360 or -180 to 180 - in polar context they are identical if you impose the "wrap" at the right level. Impose it at the function level, when the user modifies the data, with options - not at the interaction/view level.

I don't want the cursor position to be interpreted as crossing some singularity - I think this is the crux of the discussion between us - I just don't think it's a good idea to put those "real world" bounds on component windows. Put that functionality in the operations we perform on the data. What if I draw a coordinate at 95.6 Lat? Should Manifold ignore it? Interpret it as 90 - 5.6 to the south? Over the pole and down the "other side" of the world as it would be on a spheroid? It's endless and depends on your data model. I think it should just leave it alone, at least until I perform an operation in which 90+ lats make no sense.

I'm going on a bit, I'm not exactly 100% clear on this but hopefully we can work it out.

EDIT: this was discussed a lot a few years ago, maybe even back on Manifold-L. I've kind of settled into a habit of (knowing about and ) not allowing Manifold's destruction of data and using other programs when I want longitude > 180. The "Use a projection" advice is incredibly single-program-user-centric, but I've not found a fully consistent description of what I would want Manifold to do here - so I've settled on habits that remove the problem. I appreciate the encouragement to lose that habit.

https://github.com/mdsumner

This would be so much easier face to face (to face to face to face). It has "Australasian User Meeting" written all over it.

I'm glad you want to see this really truly solved too.

And I do now get a feeling for the picture you have in your head, of what makes sense to you. Good.

Perhaps two solutions would be better than one, so long as Manifold could intuit what was appropriate.

Try this, if you've got a second.

New project. New drawing. Assign CS: Orthographic, centres 0, 180. Zoom out a bit and draw a box straddling 180°. Do Points, open the table and look at the intrinsics for the points.

I get a nice set like this: 173.4981, -2.2430 173.4852, 4.2414 -176.6558, 4.2414 -176.6624, -2.2430

I think that this is exactly how this simple exercise should turn out. (And the fact that we can do it at all is due to YOU and to the nice people in tech.)

I've just done the same exercise using Vertical Perspective, and it also works. (I prefer VP to Orthographic, since it looks more real. I use 363,300km, the perigee of the moon, as the viewing distance—being a child of the late 60s.)

Lambert Azimuthal Equal Area also works. Which is useful, because it's an appropriate projection for mapping the Pacific basin as a whole. So does Azimuthal Equidistant.

It's looking as if the azimuthal projections can perform at least this simple exercise correctly.

But the cylindrical and pseudo-cylindrical projections, if centred on 180°, either return nonsense coordinates all over (Gall) or blank corrdinates east of 180° (Mercator, Transverse Mercator, Cylindrical Equal Area, Cylindrical Equidistant, Eckert IV, Mollweide, Sinusoidal, Robinson, Van den Grinten), or all blanks (Van den Grinten IV).

In Mollweide, for example, you can draw, but the status bar goes blank when you're east of 180. The resulting table shows longitude for the two points west of 180 (i.e. in the eastern hemisphere), but [Longitude (I)] is blank for the points to the east (in the western).

Which is bad because the pseudo-cylindricals are generally the best option for mapping the entre globe, and the cylindricals are good for large parts of it. Both families must be[come] just as usable when centred on the Pacific as when centred on the Atlantic.

Focussing on a tiny exercise like this might be a step towards saying something useful to tech. It seems to me that unless this exercise works, for a given projection, the projection will not work with real data. Fixing this symptom, where indicated, may not be sufficient, but I think it will be necessary.

[It's impossible to do the same exercise in Long/Lat, since we can't specify a centre longitude for that CS. It always divides at 180. This is a different problem. Ultimately, we should be able to store drawings contiguous across 180° in unprojected form.]

I think that this is exactly how this simple exercise should turn out.

Agreed, but not for X (I), Y (I) - which should be monotonic increasing always, like screen position (?). If "Latitude / Longitude" is the projection in use, then Longitude (I), Latitude (I) can do that. ;)

Actually, I never thought about the separation that way before. That might be a workable model. Why can't Manifold control everything in [-180, 180, -90, 90] with "Longitude/Latitude (I)" but let "X/Y (I)" be in whatever range we want? . . . arguably Lat really should be constrained, since it wouldn't make sense to "wrap" around N-S . . . Not sure that fits the underlying intention of the difference though.

I'll put together some examples, and see how GDAL handles different things too.

https://github.com/mdsumner

It's not clear what should happen with images/sufaces, since the intrinsic Lat/Lon would imply a disjoint raster with a large invisible region centred on Greenwich - but sure Manifold can do whatever it needs with Lat/Lon (I) while allowing the component to really straddle the Pacific in line with X/Y (I).

?

EDIT: note that this is a workaround for reprojecting a Pacific raster from longlat - copy the western/RHS side to a new component, Assign projection to lon = -180 and copy paste that (with auto-expansion) to the original - you'll get an (Indian) ocean of invisible pixels but this will be nice projected rather than losing pixels.

https://github.com/mdsumner

The plot thickens.

Orthographic Drawing as you describe. Map with Lat/Long drawing that is Pacific centric (attached SHP). Note that Simplify, Normalize Topology, Export and Import do not adversely affect this 180-straddling drawing.

If I create a map with the Drawing and World2 (using Lat/Long of World2), make Drawing active and add points at > 180 they appear 360 degrees to the left. If I activate the World2 drawing add points at >180 they are created in that position.

Attachments:
World2.zip

https://github.com/mdsumner

That's funny. So this is because the Long/Lat drawing uses longitudes > 180° (as it does), but the Orthographic drawing can't parse them?

A slight variation is to create the point in World2 first, turn on snap to points, then create the point in Drawing. Result:

Longitude of 240.8474° in World2 maps to longitude -119.1526° in Drawing

Difference 360, as you say. So what's actually happening, and why?

(Commenting first on 41527.)

I had exactly the same thoughts, but in cruder form, and I think the way you put it is absolutely right. "Longitude/Latitude (I)" should be constrained within the conventional range (by wrapping/rotation), while "X/Y (I)" can be allowed greater latitude (so to speak; actually longitude).

Plus, there would still be room for intelligent translation of source data marked "Long"/"Lat" having values outside the orthodox range, into the intrinsics, by a wrapping function (not truncation) on import/linking/paste.

Same intuition about the poles, too. I'm not sure if this is a sufficient reason, but the poles are in their own category. They aren't arbitrary, as any dividing meridian is, but real features of the globe, physically (because it spins about them) and mathematically (because it's squashed in their axis).

(To your next posts in a sec.)

because it spins about them Nup...complicated by precession.

Aussie Nature Shots

That's a joke right? The precession axis is spinning in our (GIS) reference frame - our datum is Geocentric or Geodetic, not Cosmocentric . . .

https://github.com/mdsumner

Thanks you chaps for making me learn what precession is. I had no idea the Earth did that too.

No joke, just a red herring because I thought Tim had the image of an evenly spinning earth- and maybe he did.

Aussie Nature Shots

Um, I did.

So what I would like to know next (another red herring) is whether the "rotational" poles shift upon the Earth as the axis of rotation precesses in solar/celestial/cosmological space. If I'm following, they don't. They're fixed with respect to the Earth itself. Right? And I think that's what Mike meant.

Not fixed in the long term, but it might be time to read Foucault's Pendulum if you haven't already.

;)

https://github.com/mdsumner

One of my favourite books! But it's years since I read it. Time to revise.

I realize it's been 10 years since I read it, on Macquarie Island. The concept of "no fixed point" remains with me.

https://github.com/mdsumner