Definition of a point.

[SamMousa]

I think you mentioned this is something to be discussed.

What is the minimum requirement for defining a point?

There are obviously many ways to represent a point, I think the library needs to have a basic representation. I think most stuff uses WGS84 for that.

We should always be able to express a point in any coordinate / projection system as a Point in our basic representation.

So then a Point has coordinates in multiple (if not all) projections. A Point represents a place, a place can have many different coordinates in many different projections.

Should we separate Point and Coordinate?

A projection would then just be used to get a different set of coordinates, a coordinate is always connected to a projection, but a Point is always the same. If you project a Point then the Point does not change, its coordinates do.

[judgej]

Okay, I have three types of point identified:

• Geocentric is an x,y,z point from some central origin (the datum, which is defined relative to the standard datum).
• Geodedic is a lat/long and optional height, from an ellipsoid (which also has a datum).
• Projected is a x,y and optional height point in some kind of projection. What x and y means, will depend on the projection, and may also require further metadata to provide context, such as a UTM zone, or hemisphere indicator, or grid square.

A projected point is usually meaningless without that additional metadata that is in the projection config. For example, there are 60 UTM zones, and both a north and south hemisphere. For any single x,y UTM point, there are 120 places on earth that it could be pointing to - knowing the hemisphere takes it down to 60, then the zone takes it down to exactly one.

Now, if converting say a GB Ordnance Survey coordinate to a UTM point, for that to make sense, we need to calculate both the x.y UTM point that represents, AND the zone and hemisphere - one flag planted in London will convert to these four pieces of information to define the UTM point. However, the zone and hemisphere is in the projection, while the x,y is in the point, in Proj4. That always felt wrong. I don't know whether there is some fundamental reason for this, or whether it just made coding Proj4 back in 1978 just that little bit easier and it kind of stuck.

Does that make sense? I've never seen this particular point raised anywhere, so I think perhaps I am just going mad...?

[judgej]

There are also much more complicated points that are not based on a simple ellipsoid, but also include hundreds or thousands of local mappings, like the earth is made of a series of squares, each with their own defined offsets from an approximate ellipsoid. I'm not touching that with a barge pole, but I guess room needs to be left to slip it in if someone does. I guess that would be a variant of a projection. All the projections we are dealing with so far have a mathematical formula to map between the WGS84 geodetic point (the forward and reverse methods). The more complex projections would not use a simple mathematical formula, but would pull in lookup data and have huge tables of mappings behind them.

[SamMousa]

Well a point is just a place right? No matter how I reference it, it is somewhere, not something.
For example if I say "the center of the earth" (how that is defined is another discussion) you know what I mean.
In some coordinate systems I might give it the coordinates (0,0,0).

Basically coordinates have a coordinate system just like numbers have a base.
But a Point and a Projected Point are redundant in my opinion; a Point represents a place and since there can be infinite projections there can be infinite number of coordinates for that place.

So maybe we should distinguish a Point from its coordinates?

[judgej]

I think the +nodefs option is a way of telling Proj4 NOT to use these lookup tables.

[SamMousa]

Yes, probably because in most cases it is okay to approximate these table values.

[judgej]

By treating all points as the same, Proj4 has got to where it is now - x and y could mean anything - degrees, metres, zones, etc. It means you can do totally invalid conversions on points, because the point has no metadata to indicate what it actually represents. This is one thing I am trying to solve. In theory every projected point would be a class of their own, but that may be a step too far.

[SamMousa]

Take for example the current PointInterface, it has functions: toGeocentric(). This suggests that a point can be changed into a set of geocentric coordinates.
But instead a point can be referenced using a specific coordinate system which can either be geodetic or geocentric, but there could be other properties as well, all these properties combined define a projection (correct me if I'm wrong all this stuff is quite new for me).

So then the logical "API" would be:

$point = new Point($c1, $c2, $c3);

Where $c1, $c2, $c3, are coordinates in our reference / default projection (this is a library default nothing less nothing more, it could use lat / long or whatever makes it easiest for most users).

Then a projection can get coordinates for a point like this:

$projection = new UpsideDownProjection();
$coordinates = $projection->getCoordinates($point);

Where coordinates is an unordered list of key value pair depending on the projection, optionally implemented as a value object (since there are only a few types of coordinates).

[SamMousa]

As a developer you should never do anything with X or Y if you don't know what they mean. There would be several ways to create a point, we could even remove the default constructor to reduce any confusion:

$projection = new SomeProjection();
$point = $projection->createPoint($x, $y); // Where $x and $y make sense in the context of the projection.

The projection object can then use the given parameters and convert them the base system and there only needs to be 1 type of point.

A point since it is a place, does not need to be accompanied with its projection; only coordinates need that.
I'm not suggesting to treat all coordinates the same; I'm suggesting we define each point as its coordinates in 1 projection. If you want to get coordinates for another projection all you need to do is get an instance of that other projection and request the coordinates by passing in the point.

[SamMousa]

Added advantage of that approach is that you can even force the proper parameter usage since those ->createPoint() functions don't all have to be the same.

[judgej]

Each conversion has rounding errors, so generally you want to do conversions as little as possible. This means keeping a point in its source form, or as close as you can, until you know what you are going to be doing with it. This means that I don't believe there is any "base format" for a point that would not end up introducing inaccuracies that can be avoided.

[SamMousa]

That's interesting; let me think on that!
On Mar 29, 2016 5:46 PM, "Jason Judge" notifications@github.com wrote:

Each conversion has rounding errors, so generally you want to do
conversions as little as possible. This means keeping a point in its source
form, or as close as you can, until you know what you are going to be doing
with it. This means that I don't believe there is any "base format" for a
point that would not end up introducing inaccuracies that can be avoided.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#10 (comment)

[judgej]

The diagram I have will make it clearer, showing what conversions are available, and what are not, which involve little rounding errors and which involve a lot.

[judgej]

Here is my sketch:

So what it shows is:

• A projected point can be converted to and from a geodetic WGS84 datum point. All the forumulas we have are written to do exactly that.
• A geodetic point can have many different ellipsoids and datums, and are used for different purposes and by different countries.
• You cannot convert between geodetic datums without first converting to a geocentric point and performing a datum shift in geocentric space.
• Doing a datum shift involves two steps: first shifting to WGS84, then shifting from WGS84. Either datums may already be WGS84, so a step can be avoided in those cases.

[judgej]

Now, there is something I've not got quite right on that diagram, or maybe is just not clear. A projected point can have a datum and ellipsoid of its own. For example, the OSGB national grid uses the Airy ellipsoid (not WGS84). When doing the forword and inverse shifts to a geodetic datum, I have a feeling that stays as the Airy ellipsoid, so would need shifting to WGS84 if you wanted to use it on, say, a Google map. I'm not sure if the projection is what has knowledge about the protected datum and knows how to do the shift - I'm going to have to revisit this diagram again (draw it last year so a bit rusty).

The main thing to know here is that shifting from any one point to another (each of any coordinate type or projection) will involve shifting via a small set of WGS84 stages where standard formulas can be applied. Which of the conversions and shifts are needed, will depend entirely on what the starting and ending points are. In the end, this project is all about the conversions - shove a point in one end and get another point (at the same location) out the other end. A worked example would be good.

[judgej]

Here is the spacial reference page for OSGB: http://spatialreference.org/ref/epsg/osgb-1936-british-national-grid/ Note there are many formats including Proj4, OGC WKT - they all represent roughly the same information though.

The OSGB point for Ben Nevis (the highest peak in Scotland) is NN166712 in the OSGB National Grid projection.

This will convert to a geodetic coordinate (lat/long) using the OSGB datum and ellipsoid. So we have lat/long, but it represents a different point than Google would place it on a map.

So a OSGB to WGS84 conversion is needed, which involves a datum shift and ellipsoid conversion. That happens in part by converting to geocentric coordinates to do the datum shift, then back to geodetic coordinates.

Now, if you are working out distances between two OSGB points, then all that conversion is totally unnecessary - there are formulas for calculating that kind of thing directly in the projected space.

Each projection is designed to make something easy. For some marine projections, it means you can draw a circle on a map and it shows all points equidistant from the centre. For some projections you can measure the distance in a straight line between two points and it will be an exact distance around the curvature of the earth. Other projections make calculating areas easy. They all have their purposes, many historic from when we did not all have computers and sat-navs, but all very much relevant in many industries still today.