Subject: [Geopriv] draft-marshall-geopriv-location-transform-00

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 17 Mar 2011 11:30:13 +0800

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.

---

From: "Roger Marshall" <[email-masked]>
Date: Wed, 16 Mar 2011 21:52:02 -0700

Martin:
Thank you for your comments.  Ahead of more a thoughtful response, my apologies to James above all - for depicting him with said association - rather, I'm afraid it is my only a mistake in editing on my part.

-roger.

----- Original Message -----
From: Thomson, Martin [mailto:[email-masked]]
Sent: Wednesday, March 16, 2011 08:30 PM
To: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: draft-marshall-geopriv-location-transform-00

--Martin

CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network.

---

From: "Carl Reed" <[email-masked]>
Date: Mon, 21 Mar 2011 17:24:01 -0600

In terms of transforms, there is considerable standards work in this area, 
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" <[email-masked]>
To: <[email-masked]>; 
<[email-masked]>
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.
>
> 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
>
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv
>

---

From: "Roger Marshall" <[email-masked]>
Date: Sun, 27 Mar 2011 23:18:21 -0700

Martin:
I appreciate your comments.  Please find my short responses inline.

-roger.

-----Original Message-----
From: Thomson, Martin [mailto:[email-masked]] 
Sent: Wednesday, March 16, 2011 8:30 PM
To: [email-masked];
[email-masked]
Subject: draft-marshall-geopriv-location-transform-00

At this stage, there isn't a really enough detail to properly assess the
draft.

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.

[rm - okay, I think this makes sense.]

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.

[rm - agree that simple is good.]

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.

[rm - okay, I don't think we're tied down to anything yet.]

--Martin

p.s. I was surprised to see that James is now working for TCS..., or
not.

---

From: "Roger Marshall" <[email-masked]>
Date: Sun, 27 Mar 2011 23:21:34 -0700

Carl:
Thank you for your comments.  As we start to flesh this work out, we
will seek to pull in and align with existing definitions, ontologies,
etc., where feasible.

-roger.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Carl Reed
Sent: Monday, March 21, 2011 4:24 PM
To: Thomson, Martin; [email-masked];
[email-masked]
Cc: George Percivall
Subject: Re: [Geopriv] draft-marshall-geopriv-location-transform-00

In terms of transforms, there is considerable standards work in this
area, 
including terms and definitions, ontologies, and so forth.

>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" <[email-masked]>
To: <[email-masked]>; 

> desired.  The service either produces the desired form, or an error.
The 
> you are talking about producing civic addresses, which might be
manifested 
not.