[GRASS5] projection-transformation

GRASS GRASS developer
1

Here are my examples (sorry that the shift is not
too visible - it was not my intent to stress it in these images)

http://www2.gis.uiuc.edu:2280/modviz/wake/demrdstr.gif

http://www2.gis.uiuc.edu:2280/modviz/wake/ccsoil30m.gif

DEM and soil data(polygons) seem to fit,
streams and streets - lines are shifted

the data are from

streams are
EXP 1 G:\DATA\AGENCY\CENSUS\TIGER_DATA\TIGER95\NAD83\WATER83\WTR37183.00
soils
G:\DATA\AGENCY\CGIA\SOILSURVEY\NAD83\WAKE\WA83.E00
DEM is
F:\TEMP\DATA\AGENCY\USGS\DEMS\NED\BYCOUNTY\WAKE.E00

there is no projection involved in GRASS or m.in.e00 -
all imported data should be in the same projection and with
the same datum.
So I believe that this is not a GRASS projection problem.

So it seems to be something in arcinfo export data that GRASS does not
understand correctly - are the coordinates relative and
arcinfo knows that they should be shifted but grass does not?
Or the shift is already in the arcinfo data and nobody has
noticed it - I am getting that checked.

At this point I don't remember whether I had this problem
with shape files (I did a lot of imports for those too -
thanks to the developers who contributed the tools! it is now
much easier to use arcinfo data) but I can check. I have a few more examples
in several completely different locations - all involve
shift between the raster data (DEM, Land use) and vector
line data (streams) imported from arcinfo and the shift is always
approximatelly the same.

However I must admit that it may be my problem of importing
data with different datums (although the ifnormation that I am
getting with the data says they are the same) or arcinfo problem.

I will let you know when I find something more concrete about the problem,

Helena

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

2

Merry Christmas to all!

On Fri, Dec 22, 2000 at 07:40:05PM -0600, Helena Mitasova - staff wrote:

Here are my examples (sorry that the shift is not
too visible - it was not my intent to stress it in these images)

http://www2.gis.uiuc.edu:2280/modviz/wake/demrdstr.gif

http://www2.gis.uiuc.edu:2280/modviz/wake/ccsoil30m.gif

DEM and soil data(polygons) seem to fit,
streams and streets - lines are shifted

the data are from

streams are
EXP 1 G:\DATA\AGENCY\CENSUS\TIGER_DATA\TIGER95\NAD83\WATER83\WTR37183.00
soils
G:\DATA\AGENCY\CGIA\SOILSURVEY\NAD83\WAKE\WA83.E00
DEM is
F:\TEMP\DATA\AGENCY\USGS\DEMS\NED\BYCOUNTY\WAKE.E00

there is no projection involved in GRASS or m.in.e00 -
all imported data should be in the same projection and with
the same datum.
So I believe that this is not a GRASS projection problem.

So it seems to be something in arcinfo export data that GRASS does not
understand correctly - are the coordinates relative and
arcinfo knows that they should be shifted but grass does not?
Or the shift is already in the arcinfo data and nobody has
noticed it - I am getting that checked.

Helena, please check this if possible! It would be somewhat crazy if
students in your and in my university do the same error without
knowing each other :slight_smile:

At this point I don't remember whether I had this problem
with shape files (I did a lot of imports for those too -
thanks to the developers who contributed the tools! it is now
much easier to use arcinfo data) but I can check. I have a few more examples
in several completely different locations - all involve
shift between the raster data (DEM, Land use) and vector
line data (streams) imported from arcinfo and the shift is always
approximatelly the same.

This is interesting (and a good indicator for a systematic error).

However I must admit that it may be my problem of importing
data with different datums (although the ifnormation that I am
getting with the data says they are the same) or arcinfo problem.

I will let you know when I find something more concrete about the problem,

Find attached my example with additional data:
- blue: gshhs data
- red: ARCINFO digitized data
- cross: I have read the original Gauß-Krüger-coordinates from a toposheet,
   projected this point to UTM with m.proj and imported into UTM location
   with s.in.ascii. The UTM coordinates are 377375 5953157.
   
It seems that the GSHHS west corner of the island and my manually read point
match quite well. So the problem could be
- import problem in GRASS from ARCINFO (obviously m.in.e00, v.in.shape and
   maybe v.in.arc would be affected)
- ARCINFO is having an internal error (wow, that would be a surprise)

Those having access to *other* GIS vector software - please make a few tests
to see if there is a bug in GRASS, GRASS import or somewhere else.

BTW: I have sent my ARCINFO map to Michel for investigation. Perhaps he can
find the problem in the e00 file (Michel: You have the red line dataset,
above west corner point in lat/long is 7:08:31.53E 53:42:41.51N).

Final test: I have transformed my west corner point to lat/long:
- it matches gshhs dataset
- it doesn't match ARCINFO

Again, the proj software seems to be o.k.

Markus

(attachments)

shiftsnap2.png

3

Markus Neteler wrote:

Merry Christmas to all!

Thank you, and have a happy new millenium (guess you won't be
here for the next one :wink:

BTW: I have sent my ARCINFO map to Michel for investigation. Perhaps he can
find the problem in the e00 file (Michel: You have the red line dataset,
above west corner point in lat/long is 7:08:31.53E 53:42:41.51N).

Final test: I have transformed my west corner point to lat/long:
- it matches gshhs dataset
- it doesn't match ARCINFO

Well, the e00 file seems OK, but doesn't contain any projection
information (no "PRJ" section). What say Arc/Info about the west
corner point's lat/long ? Maybe there is some information that
is not exported in the e00 file, like scale or east/north shift.
Try to export with a PRJ section (it contains values names Scale,
Xshift and Yshift that may be usefull here) and send me the e00
file again if you can.

--
Michel WURTZ - DIG - Maison de la télédétection
               500, rue J.F. Breton
               34093 MONTPELLIER Cedex 5

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

4

On Wed, Jan 03, 2001 at 11:00:21AM +0000, Michel Wurtz wrote:

Markus Neteler wrote:
>
> Merry Christmas to all!
>

Thank you, and have a happy new millenium (guess you won't be
here for the next one :wink:

I'll try my very best :slight_smile:

> BTW: I have sent my ARCINFO map to Michel for investigation. Perhaps he can
> find the problem in the e00 file (Michel: You have the red line dataset,
> above west corner point in lat/long is 7:08:31.53E 53:42:41.51N).
>
> Final test: I have transformed my west corner point to lat/long:
> - it matches gshhs dataset
> - it doesn't match ARCINFO

Well, the e00 file seems OK, but doesn't contain any projection
information (no "PRJ" section). What say Arc/Info about the west
corner point's lat/long ? Maybe there is some information that
is not exported in the e00 file, like scale or east/north shift.
Try to export with a PRJ section (it contains values names Scale,
Xshift and Yshift that may be usefull here) and send me the e00
file again if you can.

Aehm - any hints how to do that? Otherwise I'll read the instructions.

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

5

Markus Neteler wrote:

On Wed, Jan 03, 2001 at 11:00:21AM +0000, Michel Wurtz wrote:

[...]

> Try to export with a PRJ section (it contains values names Scale,
> Xshift and Yshift that may be usefull here) and send me the e00
> file again if you can.

Aehm - any hints how to do that? Otherwise I'll read the instructions.

uh... I don't know and have only a very little practical experience
on Arc/Info - sorry...

--
Michel WURTZ - DIG - Maison de la télédétection
               500, rue J.F. Breton
               34093 MONTPELLIER Cedex 5

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

6

Hi all,

as the new Makefile seems to work o.k, shall I publish
the beta11 sources?

Kudos to Justin for his immediate and complex update.
I never expected that we get such close to a GNU simulating
makefile system which is based on the old GRASS-Gmakefiles!
Great!

Sidenote: The bugtracking system is ready... I revised the
form:
http://www.geog.uni-hannover.de/grass/bugtracking/bugreport.html

which sends it's input directly to the new GRASS bugtracking system
(RT system) now. I suggested to Bernhard to add all developers to
have write access there to bugtracking. Now I'll migrate all bugs
to RT, later a script will generate the BUGS file in sources from
time to time from analysing the current RT contents.

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

7

Hi Markus

Markus Neteler wrote:

as the new Makefile seems to work o.k, shall I publish
the beta11 sources?

My vote is yes.

Kudos to Justin for his immediate and complex update.
I never expected that we get such close to a GNU simulating
makefile system which is based on the old GRASS-Gmakefiles!
Great!

Thanks. I appreciate it.

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

8

Justin Hickey wrote:

Hi Markus

Markus Neteler wrote:
> as the new Makefile seems to work o.k, shall I publish
> the beta11 sources?

My vote is yes.

Make that no. I found problems with $(VASK) mixing library files and -l
linker options in several modules. It appears to be a simple fix but I
will take a closer look to see if I can fix this quickly. Also, v.digit
now dumps core for me on IRIX (see bug report).

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

9

On Thu, Jan 04, 2001 at 01:44:53PM +0700, Justin Hickey wrote:

Justin Hickey wrote:
>
> Hi Markus
>
> Markus Neteler wrote:
> > as the new Makefile seems to work o.k, shall I publish
> > the beta11 sources?
>
> My vote is yes.

Make that no. I found problems with $(VASK) mixing library files and -l
linker options in several modules. It appears to be a simple fix but I
will take a closer look to see if I can fix this quickly. Also, v.digit
now dumps core for me on IRIX (see bug report).

Aarg!! Sorry, sorry, my fault....

It will have to do with $(VASKLIB) and $(VASK). I have simplified all
$(VASKLIB) to $(VASK). That was wrong...

Looking at src/CMD/generic/make.mid

I see that the difference is:
VASKLIB = $(LIBDIR)/libvask.a
VASK = $(VASKLIB) $(CURSES)

Perhaps you could check the Gmakefile of v.digit for that and tell me what's
correct. Then I'll go ahead and change again all the related gmakefiles
containing VASK[LIB].

Sorry for this inconvenience, but this VASK/VASKLIB stuff is still unclear
to me (like the double VECTLIB/DIG2LIB stuff).

Yours

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

10

Hi Michel,

On Wed, Jan 03, 2001 at 11:00:21AM +0000, Michel Wurtz wrote:
[...]

> BTW: I have sent my ARCINFO map to Michel for investigation. Perhaps he can
> find the problem in the e00 file (Michel: You have the red line dataset,
> above west corner point in lat/long is 7:08:31.53E 53:42:41.51N).
>
> Final test: I have transformed my west corner point to lat/long:
> - it matches gshhs dataset
> - it doesn't match ARCINFO

Well, the e00 file seems OK, but doesn't contain any projection
information (no "PRJ" section). What say Arc/Info about the west
corner point's lat/long ? Maybe there is some information that
is not exported in the e00 file, like scale or east/north shift.
Try to export with a PRJ section (it contains values names Scale,
Xshift and Yshift that may be usefull here) and send me the e00
file again if you can.

the students didn't specify any projection :-(( I hope to get the updated
file soon.
I have received another SHAPEfile with borders which matches quite good
to my other data. So three options are there:

- mistake done by the students
- e00 needs Xshift and Yshift set
- general ArcInfo problem (btw: it was PC3.5, not 8)

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

11

Markus Neteler wrote:

Hi Michel,
I have received another SHAPEfile with borders which matches quite good
to my other data. So three options are there:

- mistake done by the students
- e00 needs Xshift and Yshift set

Well, this is probably easy to handle, but I need some example for
this (the questions is : does we apply shift before or after scaling ?)

- general ArcInfo problem (btw: it was PC3.5, not 8)

For the two other options, I can't do anything :wink:

--
Michel WURTZ - DIG - Maison de la télédétection
               500, rue J.F. Breton
               34093 MONTPELLIER Cedex 5

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

12

Hi Michel,

On Thu, Jan 11, 2001 at 03:49:29PM +0000, Michel Wurtz wrote:

Markus Neteler wrote:
>
> Hi Michel,
> I have received another SHAPEfile with borders which matches quite good
> to my other data. So three options are there:
>
> - mistake done by the students
> - e00 needs Xshift and Yshift set

Well, this is probably easy to handle, but I need some example for
this (the questions is : does we apply shift before or after scaling ?)

> - general ArcInfo problem (btw: it was PC3.5, not 8)

For the two other options, I can't do anything :wink:

I have investigated some more hours...

Here the results:
- we have used "projectdefine" to add a projection in ARCINFO8
   (using the PC-ARCINFO3.5 e00 file)

-> import into GRASS is identical. The misplacement is *non-linear*.

While thinking about the problem I should describe the input dataset better:
The students have digitized the country's border from a 1:500000 paper map
of Lower saxony. Problem with this map is:
- the map is projected in Lambert Conical projection (10:30E meridian)
- the border's coordinates are given in degree, nothing else
- ellipsoid is "international"

Now the students have referenced the map to lat/long and digitized.
The misplacements are like that (compared with an other digital governmental
dataset and the GSHHS shorelines):

6° 7° 8° 9° 10° 11°
+ + + + + + 53:30°
  north sea ***(islands) *** -----
         *** ---------------- /--------------/ \
  *** --------/ | / \
/--/ \--- |
| shift: 2.5km to E | + 53 E
| 500m to S
| shift: +/- 0
|
|
/ LOWER SAXONY (northern Germany)
|
| + 52 E
| |
\ shift: 1km to W (!) |
\ 0 to S /
  \ /
   ------------\ /-----\ /
                \ / \ /
                 \ / \ /
                  ---------| \ /
                                       \ /
                                        \----------------/
                                         shift: 1.5km to E + 51 E
                                                2km to S

Let me say: I am slightly confused.
Perhaps the problem is that the map's projection is Lambert, but GRASS
et al. treat is as Geographic (lat/long)? But, then, how to get in
a map projection in Lambert if only lat/long coordinates are printed on
that map?

I am quite in the dark,
help is appreciated (especially to save the digitizing work)

Thanks for listening!

   Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

13

On Thu, 11 Jan 2001, Markus Neteler wrote:

Let me say: I am slightly confused.
Perhaps the problem is that the map's projection is Lambert, but GRASS
et al. treat is as Geographic (lat/long)? But, then, how to get in
a map projection in Lambert if only lat/long coordinates are printed on
that map?

I wouldn't expect you to get much accuracy from trying to digitize
latitude and longitude off a map in lambert coordinates, but as long as
the lambert coordinates were appropriate for the map area it doesn't seem
like the errors should be large.

I can't help much with the digitizing work, sorry. If you know the actual
latitude and longitude of several of the digitized points then you might
be able to use those in v.transform to adjust the entire file to more
nearly correct coordinates.

More rigorously, it seems like what you need are the lambert coordinates
of the map's visible latitude-longitude tics, or other points on the map
that you can use to register the map. You might be able to do something
like: 1) set up a mapset using the lambert specification for the map, 2)
build a sites file in your latlong mapset that contains the latitude and
longitude tics marked on the map; 3) use s.proj to convert the tic
locations from latlong to lambert. Use the lambert coordinates of the
latitiude-longitude tics to register the map and then redigitize in
lambert coordinates.

Roger Miller
Lee Wilson and Associates

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

14

Markus Neteler wrote:

While thinking about the problem I should describe the input dataset better:
The students have digitized the country's border from a 1:500000 paper map
of Lower saxony. Problem with this map is:
- the map is projected in Lambert Conical projection (10:30E meridian)
- the border's coordinates are given in degree, nothing else
- ellipsoid is "international"

Well... Lambert conical... that probably means that the meridian
lines converge. A test : look if distance between the 6°E and the
11°E meridian are the same at the top and the bottom of the map.

I presume this is not the case. Use the your Arc/info tic marks
and convert the lat/long values to meters in the lambert conical
projection used by the map (conformal or equal area projection ?
what are the projection's central parallel or the two parallels
used ?).
Then you can simply use an afine transformation to transform lat/long
to X,Y ; import the data in Grass in Lambert and reproject them (using
the same lambert projection parameters) in lat/long.

But I'm afraid that the non-linearity of the parallels/meridians
introduced some irreversible glitch during the numerisation process
(I guess also that the EMQ obtained when the students have referenced
and the map at the beginning of the numerisation process was a little
big when converted to km !)

--
Michel WURTZ - DIG - Maison de la télédétection
               500, rue J.F. Breton
               34093 MONTPELLIER Cedex 5

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

15

Hi all,

a short update on our map shift problems here...

On Thu, Jan 11, 2001 at 06:20:34PM +0000, Michel Wurtz wrote:

Markus Neteler wrote:
>
> While thinking about the problem I should describe the input dataset better:
> The students have digitized the country's border from a 1:500000 paper map
> of Lower saxony. Problem with this map is:
> - the map is projected in Lambert Conical projection (10:30E meridian)
> - the border's coordinates are given in degree, nothing else
> - ellipsoid is "international"

Well... Lambert conical... that probably means that the meridian
lines converge. A test : look if distance between the 6°E and the
11°E meridian are the same at the top and the bottom of the map.

Well, thi is not the case - fully non-linear shifts.

I presume this is not the case. Use the your Arc/info tic marks
and convert the lat/long values to meters in the lambert conical
projection used by the map (conformal or equal area projection ?
what are the projection's central parallel or the two parallels
used ?).
Then you can simply use an afine transformation to transform lat/long
to X,Y ; import the data in Grass in Lambert and reproject them (using
the same lambert projection parameters) in lat/long.

But I'm afraid that the non-linearity of the parallels/meridians
introduced some irreversible glitch during the numerisation process
(I guess also that the EMQ obtained when the students have referenced
and the map at the beginning of the numerisation process was a little
big when converted to km !)

I have extracted the tics out of the E00 file. They are exactly
where they should be. Then I scanned part of the map, rectified
affine with i.rectify - the drawn grids are matching well.

Solution: The students *must* have had a very bad day. I cannot
reproduce that anything is wrong with m.in.e00. :slight_smile:

But we should put an eye on that. Helena, did you find anything
new here? Something which could be reproduced?

THank you all for your time and commments on this,

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'