[GRASS5] conversions and copyrights

GRASS GRASS developer
1

Folks,

I am drafting the code needed for r.proj, v.proj, s.proj and m.proj to
convert between nad27 and nad83 data using the nad_init and nad_cvt
routines and data distributed with proj.4A.3.3.

The data distributed with proj4 are limited to conversion within the US.
Canada is undergoing a similar change. NAD83 has also been adopted in
Mexico, Central America, Greenland and among Caribean countries. I looked
briefly for the data necessary to apply similar conversions for countries
other than the US. I found that the data and software necessary to complete
the conversion for Candian locales are distributed by Canadian federal
government. The data and software are not in the public domain.

The license agreement is at

http://www.geod.nrcan.gc.ca/site/index_e/data_e/data_e.html

Strictly from a layman's perspective, the Canadian license conditions don't
appear to be compatible with the GPL. It looks like we would need a separate
license agreement in order to distribute the data or software as part of
GRASS. Can someone with more expertise than I take a look at their
conditions? Has GRASS had to deal with similar problems before?

Further, it looks like the data and software are only available for a fee. I
don't have a current need for the conversion capability, so I'm not going to
spring for the $40.00 (Canadian, presumeably) to have them ship me the
package on CD.

Roger Miller,
Lee WIlson and Associates

2

Roger Miller wrote:

Folks,

I am drafting the code needed for r.proj, v.proj, s.proj and m.proj to convert between nad27 and nad83 data using the nad_init and nad_cvt routines and data distributed with proj.4A.3.3.

Roger,

A couple of points.

  o PROJ 4.4.5 already does datum shifting, integrated with the reprojection
    operation using the pj_transform() API. You can use +datum=NAD27 and
    similar directives to enable datum conversion.

  o PROJ 4.4.5 already has support integrated for Canadian NTv1 datum shift
    files in addition to the US NADCON style data.

Rather than re-invent some of this work based on the old proj code, I
would much rather see it all accomplished in a more integrated way in
GRASS 5.1 using PROJ 4.4.5, even if that code base is just adopted into
the GRASS tree as is done now. Though, given that we are moving to more
modern use of shared libraries and so forth for 5.1 perhaps we could use
PROJ.4 in it's more natural form.

I am prepared to assist substantially with such an effort.

The license agreement you point of is not compatible with redistributing
the grid shift data. I assume this is the agreement for the NTv2 data. Is
that right? Many vendors distribute the NTv1 data which is now freely
redistributable, though it is lower resolution than the NTv2 data. I think
they are format compatible so users licensing the NTv2 data can download and
replace the NTv1 data.

Best regards,

--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent

3

On Sat, Jan 12, 2002 at 08:20:47AM -0700, Roger Miller wrote:

The data and software are not in the public domain.
The license agreement is at
http://www.geod.nrcan.gc.ca/site/index_e/data_e/data_e.html

Strictly from a layman's perspective, the Canadian license conditions don't
appear to be compatible with the GPL. It looks like we would need a separate
license agreement in order to distribute the data or software as part of
GRASS.

You are correct, the link you gave seems to be only for "Data".

Can someone with more expertise than I take a look at their
conditions?

At least not me.

Has GRASS had to deal with similar problems before?

If the software is not Free Software compatible with the GNU GPL,
we cannot distribute it. We need to write it from stratch or find
other code. There is no other way.

As for data, this is a different thing.
It cannot be distributed with GRASS.
If the users need them, they might be able to obtain it in a
different way. It is okay to work with non-free Data.

Regards,
  Bernhard

4

On Saturday 12 January 2002 10:01, Frank Warmerdam wrote:

  o PROJ 4.4.5 already does datum shifting, integrated with the
reprojection operation using the pj_transform() API. You can use
+datum=NAD27 and similar directives to enable datum conversion.

  o PROJ 4.4.5 already has support integrated for Canadian NTv1 datum shift
    files in addition to the US NADCON style data.

Rather than re-invent some of this work based on the old proj code, I
would much rather see it all accomplished in a more integrated way in
GRASS 5.1 using PROJ 4.4.5, even if that code base is just adopted into
the GRASS tree as is done now. Though, given that we are moving to more
modern use of shared libraries and so forth for 5.1 perhaps we could use
PROJ.4 in it's more natural form.

Frank,

Thanks for the feedback. I hadn't thought to look for newer versions of the
proj library. Certainly you are right that a more integrated approach is
better.

Unfortunately I can't wait for 5.1. I and many other people working in North
America have to deal with the nad<->nad conversion on a nearly daily basis.
I think the grass developers would be getting far more pressure to offer this
capability if 5.0 had more North American users. As it is, anyone using
GRASS now in North America has to either ignore the conversion problems or
cobble together some kind of work-around solution.

For those not aware, the nad27->nad83 conversion is not just a datum shift.
There were errors in the nad27 datum that are corrected in the nad83 datum,
and the conversion between the two data includes a datum shift plus some
error corrections. As a result, the nad27->nad83 conversion can't be
completed with generalized datum shift formulas.

I think my first step will be to look into the newer version of the proj
library. From there I need to continue on my present course, because I want
to have this capabiity in place on Monday.

My solution is probably not something that anyone wants for 5.1, but maybe it
can be incorporated in 5.0 for the sake of the users in the US and southern
Canada.

I am prepared to assist substantially with such an effort.

I'm glad to hear that. I looked briefly at the outline of GRASS's more
general datum conversion capability in the programmer's manual. That looks
like more than I would want to tackle by myself.

The license agreement you point of is not compatible with redistributing
the grid shift data. I assume this is the agreement for the NTv2 data. Is
that right?

That's right. However, I had the impression that the document was actually a
generic condition that they applied to most or all of their data. There is a
similar but separate document that covers software.

Roger Miller
Lee WIlson and Associates

5

On Sat, Jan 12, 2002 at 10:29:45AM -0700, Roger Miller wrote:

On Saturday 12 January 2002 10:01, Frank Warmerdam wrote:

[..]

Unfortunately I can't wait for 5.1. I and many other people working in North
America have to deal with the nad<->nad conversion on a nearly daily basis.
I think the grass developers would be getting far more pressure to offer this
capability if 5.0 had more North American users. As it is, anyone using
GRASS now in North America has to either ignore the conversion problems or
cobble together some kind of work-around solution.

Hi Roger,

the GRASS 5.1 is less far than you may feel: It is available in CVS
/grass51

cvs -z3 co grass51

The interesting points are
1. recently a new Makefile system was implemented
2. the configure links the GRASS 5.0 code into 5.1 automatically
3. it fully compiles
This work was done by Radim Blazek as he needs a full environment
for the 3D/DBMS vector development.

Especially (2) is interesting: Like that we can experiment with
new code in /grass51 without loosing the connection to 5.0. I
recommend to develope the new code in /grass51 with a link to
the latest PROJ4.4.5 (preferably as shared lib). As only three
modules (or four?) are affected, the code handling is simple.

Current drawbacks:
- the /grass51 will become really functional when then merge back
   from release to exp. tree is done as it need code from the experimental
   stuff (for the vector).
- at time it is functional when built against the oldish experimental
   code

But, after releasing 5.0pre3 next week we can directly merge back the
code. I suggest Wednesday for the 5.0pre3 tagging to give a few more
days for the urgent fixes to be expected.

It would be great to welcome more testers in the /grass51 section.

Markus

6

On Sat, 12 Jan 2002 10:29:45 -0700, Roger Miller <rgrmill@rt66.com> wrote:

[snip]

Frank,

Thanks for the feedback. I hadn't thought to look for newer versions of the
proj library. Certainly you are right that a more integrated approach is
better.

Yes. And a more general solution (or set of solutions) is needed. The
biggest problem with implementing any solution is the inadequate way that
coordinate systems are referred to in GRASS. This, unfortunately, affects
more modules than those specific to projection (and that's why it was put
off to 5.1).

Unfortunately I can't wait for 5.1. I and many other people working in North
America have to deal with the nad<->nad conversion on a nearly daily basis.
I think the grass developers would be getting far more pressure to offer this
capability if 5.0 had more North American users. As it is, anyone using
GRASS now in North America has to either ignore the conversion problems or
cobble together some kind of work-around solution.

Personally, I'd rather not see another partial fix get stuck into GRASS. But,
I'm of the opinion that a general solution cannot be cleanly implemented until
the "system" for specifying coordinate systems is cleaned up, and itself
generalized ("Unknown/X-Y", "Geographic", "Projected (inc. Geographic)").

--
Eric G. Miller <egm2@jps.net>