Subscribe to this thread
Home - General / All posts - ASCII Gridded XYZ Projection
joebocop
514 post(s)
#24-Apr-19 05:00

I can't get imported ASCII gridded YXZ data to project correctly in M9.

I have a few gigabytes worth of space-delimited XYZ files having .txt file extension.

Coord values are in EPSG:3154. Lines are x y z as...

591934.250 7028088.750 824.74

591934.750 7028088.750 824.80

591935.250 7028088.750 824.89

591935.750 7028088.750 824.86

591936.250 7028088.750 825.01

591936.750 7028088.750 825.07

591937.250 7028088.750 825.14

...

To import them into M9 I

- Click File --> Import,

- Choose the "All Files (*.*)" Open File Dialog file type filter,

- Highlight the .TXT files, and then

- Change the Open File Dialog filter to "XYZ Files (*.xyz)"

- Click "Import"

The file import, and the resultant image components are assigned EPSG:3857. Hovering the mouse pointer around the image shows the correct (for EPSG:3154 anyway) coordinate values at the cursor location.

The images, of course, do not align correctly with EPSG:3154 layers in a map component.

With the image component open, I go to the Contents Pane, and select the Component (CTRL+1) dropdown. I select "Repair Initial Coordinate System", and choose EPSG:3154.

Now when I move the mouse pointer across the image, the coordinate values start at 0,0 in the bottom right hand corner. Obviously, the image does not display at the correct location in an EPSG:3154 map.

What on earth am I doing wrong here? QGIS, GlobalMapper, Arc*, SIS Desktop Express all import and project these data correctly.

tjhb
10,094 post(s)
#24-Apr-19 05:22

See here (not obviously applicable, but bear with it, it is right).

This is a design error, and a trap.

joebocop
514 post(s)
#24-Apr-19 06:02

What the.

So "Repair Initial Coordinate System --> EDIT COORDINATE SYSTEM" is the ticket.

Not "Repair Initial Coordinate System --> Click_On_A_Favourite"

Thank you again.

tjhb
10,094 post(s)
#24-Apr-19 06:21

That's exactly it.

Obviously it needs fixing. If I knew how it should be fixed, I would say so. That is tricky.

tjhb
10,094 post(s)
#24-Apr-19 06:52

If you have an idea, send it in.

Elegant necessary ideas tend to be integrated just like breathing, out... in. (With the adopted idea much improved.)

But elegant ideas are hard.

Dimitri


7,413 post(s)
#24-Apr-19 07:51

and the resultant image components are assigned EPSG:3857.

Just to confirm... Could it be that they are not assigned EPSG:3857 but instead have a placeholder shown in red color for Pseudo-Mercator (EPSG:3857) indicating that the initial coordinate system must be assigned?

In that case, it is a routine matter of Assigning the initial coordinate system. If for some reason the format specifies the wrong projection (or the dataport for whatever reason assigns the wrong projection), then it is a Repair coordinate system thing.

From Tim:

This is a design error, and a trap.

I don't understand what you mean. If the image is imported with the wrong coordinate system assigned, that's easy to fix by using Repair Coordinate System. That's what it is there for. If the coordinate system you want is in the Favorites list, you can specify it with one click. If it is not one of the Favorites, no problem... use Edit Coordinate System and specify whatever is the desired coordinate system.

As to why the image is imported with the wrong coordinate system assigned (if that is what is going on), that's a routine matter of exploring what is going on with a particular set of files - routine, because given Manifold's ability to import/link hundreds of formats/data sources and subformats, it is completely routine to have such issues pop up from time to time. Either the file is specifying the wrong projection or Manifold is importing it without getting the right projection (often a matter of a sidecar file, the evolution of commonly accepted practice not set forth in any standard but now routinely met, etc.).

If you have a format where Manifold doesn't grab the projection but other packages do, send that in as a Suggestion or bug report.

Dimitri


7,413 post(s)
#24-Apr-19 08:44

I don't understand what you mean.

On second thought, I'll venture a guess, which could be wrong given the sprawling nature of the thread referenced. :-)

The basic issue seems to be that Manifold treats a coordinate system definition as the explicit statement of all parameters relevant to a coordinate system. That includes parameters such as offsets and scaling (or units). EPSG 3857 with zero offsets is a clearly defined coordinate system. If everything is the same except offsets are non-zero, that's a different coordinate system, with said non-zero offsets duly noted in the JSON string that exactly specifies the coordinate system.

That Manifold explicitly specifies all parameters of interest is a good thing. That provides an explicit statement so you can always look and see exactly what the coordinate system is supposed to be. None of this "Oh, this is what the coordinate system is supposed to be. Except when I use the same words to mean something different."

That conflicts with what some other systems do, where they use the same name of a coordinate system to refer to what in actuality are different coordinate systems, different because they use different offsets, different units or other differences.

You run into that difference in approach with images, where common practice has two inelegant aspects to it: first, formats are used which do not fully convey all projection info of interest. They'll convey some of it, like offsets, but other parts are talk therapy that must be harvested from metadata or other babble. Second, they'll say an image is in some projection but with changes in the form of offsets, rotation or some other customization of the projection specific to that particular image.

In Manifold's case, if you read metadata saying the image is in EPSG:3857 and you tell the system to apply EPSG:3857 it will do that, including the zero offsets that are built into that coordinate system. In the case of Arc, if you tell it to apply EPSG:3857 it doesn't think about offsets so it just leaves those whatever they are.

With Manifold, you are free to define a custom version of EPGS:3857 that is specific to a given image where the offsets or other parameters in that customized version are those used in the coordinate system of the image. You can then save that to Favorites and you'll get a one-click ability to apply that correct coordinate system to the image.

The inelegance arises from having to deal with inelegant formats and with sloppy application of precise notions. It is in some ways analogous to guys who claim to support EPSG but then ignore axis ordering they explicitly specify using EPSG, that YX thing again.

The simplest solution is similar to what was done to live with slacker disregard for EPSG axis ordering: add a checkbox that, in effect, says "don't apply the precise definition of the projection, because we're not being literal: just apply that part of it not involving offsets or scales." That could be labeled "Preserve offsets/scales" or something similar.

For guys who work with many images like this, you could put that in a Tools - Option setting, perhaps preserving offsets/scales by default just like the default is to use slacker disregard for EPSG axis ordering. That would avoid having two forms of menu lists applying Favorites in a one-click way, the precise form and the not-quite-literal form.

tjhb
10,094 post(s)
#24-Apr-19 13:34

Exactly. Well said.

(I laughed out loud at the "talk therapy" stuff. No amount of metadata is too much, provided it is taxpayer metadata.)

I think it should be less easy to override image offsets and scales without meaning to. Your suggestion sounds good. Something like that could likewise simplify importing, say, a few dozen images at a time.

joebocop
514 post(s)
#24-Apr-19 17:26

Thanks Dimitri.

In my case, the initial "assigned" coordinate system is not presented in red; Manifold lists the coord system in black, and the option I am presented is not "Assign Initial", but rather "Repair Initial..."

In this case, Manifold appears "certain" of the projection, and simply clicking the correct projection from the "Repair" context menu does not succeed. I have to instead click "Edit Coordinate System", then search for the string "3154", and then click ok.

Would be cool if clicking on the "favourite" projection listed in the Repair menu produced the result I am after.

Attachments:
mfd_assign_coordsys.png

Manifold User Community Use Agreement Copyright (C) 2007-2021 Manifold Software Limited. All rights reserved.