Hi georeference.org,

I am using Manifold 9 in Windows 11. I have a simple map with a number of points in Latitude/Longitude projection. My aim is to create "Lttd" and "Lngtd" columns in the map's table showing the latitude and longitude for each of the points.

I have defined the columns as float64 with the following expressions:

Lngtd: VectorValue(GeomCoordXY([Geom],0),0)

Lttd: VectorValue(GeomCoordXY([Geom],0),1)

When I choose one of the points, the live coordinate readout (after setting it to in the lower right corner of the map window indicates that the longitude and latitude are 55.306104°W and 49.281022°N respectively. However, the values for Lngtd and Lttd in the map's table show up as 34278.92950783701 and 3748.101411567959.

After some poking around, it appears that the values reported for Lngtd and Lttd in the table are actually the "Pixels / Stored" values for the point(s).

My question is: how do I convert these values to longitudes and latitudes? I have searched the documentation (as well as georeference.org) for examples but have not come up with any procedure that I might follow.

I would be grateful for any help with this.

Cheers, Jim

Hi, you are not using correct words to describe your situation, so helping is difficult. For example, a map have no table and cannot contain points. Please make sure to describe your case with Manifold's terms to get better help.

Hi Everyone,

My apologies. I was incorrectly using "map" where I should have been using drawing. My corrected post follows. Also, I have attached an M9 .map file that demonstrates the issue. The drawing/table combination that I'm working with is "Trbn-AllN-WFL029-Ggrphc" drawing and "Trbn-AllN-WFL029-Ggrphc Table" table.

Hi georeference.org,

I am using Manifold 9 in Windows 11. I have a simple drawing with a number of points in Latitude/Longitude projection. My aim is to create "Lttd" and "Lngtd" columns in the drawing's associated table showing the latitude and longitude for each of the points.

I have defined the columns in the table as float64 with the following expressions:

Lngtd: VectorValue(GeomCoordXY([Geom],0),0)

Lttd: VectorValue(GeomCoordXY([Geom],0),1)

When I choose one of the points, the Position pane in the status bar readout (after setting it to "Latitude / Longitude") in the lower right corner of the drawing window indicates that the longitude and latitude are 55.306104°W and 49.281022°N respectively. However, the values for Lngtd and Lttd in the drawing's associated table show up as 34278.92950783701 and 3748.101411567959.

After some poking around, it appears that the values reported for Lngtd and Lttd in the table are actually the "Pixels / Stored" values for the point(s).

My question is: how do I convert these values to longitudes and latitudes? I have searched the documentation (as well as georeference.org) for examples but have not come up with any procedure that I might follow.

I would be grateful for any help with this.

Cheers, Jim

Attachments:
Test.map

I don't know the explanation. It is weird. But I exported your drawing as a shapefile and imported it back. Then I ran

Update [Trbn Table] Set [x] = GeomCoordX(Geom,0)

and the value in X was good.

Don't know the details on what is going on, but I have had good luck using the code VectorValue(GeomCenter(CoordConvert(@converter, [Geom]), 0), 1) as a computed fields to calculate the lat and long for my address points. Of course, change the 0 to a 1 for respective lat vs long.

Hi Mike and Vincent,

Many thanks for your comments. They were much appreciated.

I tried Mike's suggestion. I tried to directly create the Latitude and Longitude fields in the table using:

VectorValue(GeomCenter(CoordConvert(@converter, [Geom]), 0), 1)

This didn't work. I got an error trying to create the column. I then did some more poking around and found the "Queries that Add Computed Fields" section in the documentation (Help > Documentation > Start > User Manual > Basics > Computed Fields). It is near the end of this section of the User Manual, and lists a series of queries by Riivo Kolka. One of these is "Latitude and Longitude Coordinates". I used this very helpful query to create the Latitude and Longitude fields in my table. It worked perfectly. Interestingly when I go back to the table Schema, the "Expression" for each of the columns is just as Mike had suggested.

At this point, I thought that there is some magic going on in the background that I definitely didn't understand. However, after some further poking around, I discovered that there was an "Expression Context" associated with the "Expression" that Mike provided above. The Expression Context was:

VALUE @converter TABLE = CALL CoordConverterMake(CoordSystemDefaultLatLon(), ComponentCoordSystem([Trbn-AllN-WFL029]));

I think this is the magic in the background. I definitely still don't fully understand it but am beginning to think that I can see a bit through the fog.

Regardless, I now have columns in my table which, importantly, I can format as deg-min-sec which are required for submission to authorities.

Again, many thanks to Mike and Vincent for the useful comments that got me down the road to implementation, if not full understanding.

Cheers, Jim

What seems to be going on is that your original table, or at least the geom field you used, had data in a projection that was not latitude/longitude projection.

A geom field in Manifold stores X, Y, and Z coordinate numbers, three numbers, all within a single field. If you want to fetch just one of those numbers you use one of the GeomCoord... SQL functions. You could use GeomCoordXY (which gives you a two-number vector and then you pull a single number out using VectorValue) as you did or, as some people find easier, use the GeomCoordX, GeomCoordY, and GeomCoordZ functions, which provide a single number directly.

But the only thing those functions do is pull the desired coordinate number out of the set of three coordinate numbers stored in the geom. They don't reproject that number for you if you want that coordinate number to be in some coordinate system that is different than the coordinate system used in the geom.

In your case, if you used a GeomCoord function to pull an X or Y coordinate number out of the geom triplet, and that number looked weird, like 18038489.0300 instead of something that looks like a lat (+- 90) or lon (+- 180), then the geom from which you pulled that coordinate wasn't in a latitude/longitude projection. It used a different coordinate system.

If you have a geom that uses a different coordinate system and you want to get the coordinates as if you were using a latitude/longitude coordinate system, you have two choices:

1) convert the geom field to latitude and longitude. In the simple case where a table has only one drawing associated with it (and thus only one geom field) you just reproject the drawing into lat/lon and you're done. Now, when you get the coordinates using a GeomCoord... function, the numbers are lat/lon numbers.

2) use an SQL expression to compute the lat/lon equivalent on the fly. That's what the SQL snippets in the computed fields topic do. They don't assume your geom is in lat/lon but instead add some SQL (the CoordConvert... parts) that does a conversion on the fly just in case your coordinate system is not lat/lon.

Note also two important concepts:

- A latitude/longitude projection is just a coordinate system like all the others. It's not some unique basis for truth. It's just a different projection.

- There is no single, authoritative latitude/longitude coordinate system, no more than there is a single variety of potatoes. The lat/lon system which uses a WGS84 datum is very popular, so popular that speaking casually people (and Manifold documentation) often assumes that's what you mean when you say "lat/lon projection."

But in reality there are hundreds, if not thousands, of different lat/lon coordinate systems that are differentiated by the datum used. The datum, speaking casually, is the choice of Earth ellipsoid and the position (where the coordinate system is centered within the ellipsoid) of the ellipsoid. Experienced operators never take it for granted that the lat/lon system being used is the one using the WGS84 datum. They always check, especially for older data. See the Latitude and Longitude are Not Enough essay.

Hi Dimitri,

Many thanks for the explanation. Based on that, I went back and looked at what (I think) I had done.

I started with a drawing in UTM. I duplicated the drawing and table and then reprojected the duplicate drawing to what I thought was a latitude/longitude projection. The one I used was "WGS 84 (EPSG:4326)". I chose this because I thought that it would ensure that the Datum would be WGS 84. I looked at the definition of this projection and it is as follows:

{ "Name": "WGS 84 (EPSG:4326)", "System": "Latitude \/ Longitude", "Base": "WGS 84 (EPSG:4326)", "Axes": "YX", "MajorAxis": 6378137, "Eccentricity": 0.08181919084262149, "Unit": "Degree", "UnitLatLon": true, "UnitScale": 1, "UnitShort": "deg" }

I compared it to the definition for the "Latitude / Longitude" projection as follows:

{ "Name": "Latitude \/ Longitude", "System": "Latitude \/ Longitude", "Base": "World Geodetic 1984 (WGS84)", "Axes": "XYH", "MajorAxis": 6378137, "Eccentricity": 0.08181919084262149, "Unit": "Degree", "UnitLatLon": true, "UnitScale": 1, "UnitShort": "deg" }

I understand that there are subtle differences (Axes is YX for the former and XYH for the former) but I thought (now evidently incorrectly) that WGS 84 (EPSG:4326) was also a "Latitude/Longitude" projection (or at least basis, if not projection). In any case, when I tried to create a table field with the longitude (for example), I ended up with what appears to be the "Pixel / Stored" coordinate, which prompted my original post.

After reading your explanation, I went back and started with the original UTM drawing, duplicated the drawing and table and re-projected the duplicates using "Latitude / Longitude" and not WGS 84 (EPSG:4326). When I did this, the table field created with "GeomCoordX([Geom], 0) behaved exactly as I hoped it would and gave me the correct longitude.

Another lesson learned.

Many thanks to everyone for their assistance!

Cheers, Jim