including terms and definitions, ontologies, and so forth.
For example, for coordinate reference system transforms (CRS):
From ISO 19111 (Joint OGC/ISO document) A coordinate transformation or
coordinate conversion operates on coordinates, not on coordinate reference
systems. Coordinate operation has been modeled in ISO 19107 by the operation
"Transform" of the GM_Object class. Changing the coordinates of a point or
set of points referenced to a coordinate reference system associated with
one datum to make them refer to another a coordinate reference system
associated with a different datum is called a datum transformation.
(Strictly, this is a misnomer: it is the coordinates that are being
transformed). In the case of vertical datums, the transformation consists of
simply adding a shift to all height values - often the shift is constant. In
the case of plane or spatial coordinates, a datum transformation often takes
the form of a similarity or Helmert transformation, consisting of a rotation
and scaling operation in addition to a simple translation. In the plane, a
Helmert transformation has four parameters; in space, seven.
As can be seen, there are very specific rules and approaches to coordinate
transformation.
In ISO 19119: Services, there is a taxonomy of geoprocessing services
including numerous transforms, such as vector to raster, raster to vector,
address to point, point to address, conflation, and on and on.
The point is that Martin is correct, there are a potentially a very large
number of geo transforms that can be applied to LO content. I need to read
draft-marshall-geopriv-location-transform closely so that I can provide more
specific input.
Regards
Carl
----- Original Message -----
From: "Thomson, Martin" <Martin.Thomson@commscope.com>
To: <geopriv@ietf.org>;
<draft-marshall-geopriv-location-transform@tools.ietf.org>
Sent: Wednesday, March 16, 2011 9:30 PM
Subject: [Geopriv] draft-marshall-geopriv-location-transform-00
> This new attempt on the old idea is a good sign that the authors are
> intent on getting this right. I like that.
>
> At this stage, there isn't a really enough detail to properly assess the
> draft.
>
> I think that the basic model that is hinted at in Section 8 could be
> structured differently. The current suggestion has several points of
> articulation. Civic has a range of profiles, which is probably only one
> layer; but geodetic locations have both CRS and shape. That leads to a
> plethora of transformations when all combinations are considered.
>
> When each is combined, both input and output of the transformation need to
> be described with a subset of: location type, civic address profile, civic
> address language, geographic CRS, geodetic shape, and anything else that
> is later added.
>
> Rather than specify a whole range of x-to-y transforms, in all the
> combinatorial glory that implies, this could be made quite simple. The
> service accepts a location and a description of the location that is
> desired. The service either produces the desired form, or an error. The
> error can indicate that the target form is not supported, or that the
> input form is not one of those that are supported for the output form (or
> the range of other errors specific to the transformation). In either
> case, the service might be able to describe the forms that it desires.
>
> That all assumes that you are using a request-response model for the
> protocol, which would seem to be the case, but that detail is absent. I
> can think of other models, some of which could have advantages. For
> instance, if you could imagine using REST and even HTTP content
> negotiation for the transformed object, it might work, particularly when
> you are talking about producing civic addresses, which might be manifested
> as discrete resources.
>
> --Martin
>
> p.s. I was surprised to see that James is now working for TCS..., or not.
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
