[GRASS-dev] Projection-problem

GRASS GIS GRASS GIS developer
,
1

Dear lists,

[first posted to grass5, therefor reposted, since it did not make the
way to grass-dev]

I have a strange problem regarding Oracle spatial datasets.

My dataset has the following projection:

Extent: (4452550.890000, 5324953.370000) - (4479484.079834,
5345694.049805) Layer SRS WKT:
PROJCS["GK Zone 4 (DHDN)",
    GEOGCS[,
        DATUM[,
            SPHEROID["Bessel
1841",6377397.155,299.1528128],582.000000,105.000000,414.000000,-1.040000,-0.350000,3.080000,8.300000],
PRIMEM["Greenwich",0.000000], UNIT["Decimal
Degree",0.01745329251994330]], PROJECTION["Transverse Mercator"],
    PARAMETER["Scale_Factor",1.000000],
    PARAMETER["Central_Meridian",12.000000],
    PARAMETER["False_Easting",4500000.000000],
    UNIT["Meter",1.000000000000],
    AUTHORITY["Oracle","82032"]]
[Columns follow here]

Note that the datum-parameter is empty.

I can "export" the data into shp using ogr2ogr which results in a shape
with the following proj-information:

Feature Count: 10584
Extent: (4452550.890000, 5324953.370000) - (4479484.079834,
5345694.049805) Layer SRS WKT:
PROJCS["GK Zone 4 (DHDN)",
    GEOGCS[,
        DATUM["Mean_Sea_Level",
            SPHEROID["Bessel
1841",6377397.155,299.1528128],582.000000,105.000000,414.000000,-1.040000,-0.350000,3.080000,8.300000],
PRIMEM["Greenwich",0.000000], UNIT["Decimal
Degree",0.01745329251994330]], PROJECTION["Transverse Mercator"],
    PARAMETER["Scale_Factor",1.000000],
    PARAMETER["Central_Meridian",12.000000],
    PARAMETER["False_Easting",4500000.000000],
    UNIT["Meter",1.000000000000],
    AUTHORITY["Oracle","82032"]]

Here you can see that the Datum now contains "Mean_Sea_Level". When
inspecting the written .prj-file from the shape I cannot find any entry
in the datum-parameters like "Mean_Sea_Level".

Is this the normal behaviour? I am asking, because GRASS segfaults
when using v.in.ogr with location=newloc parameter enabled.

I am using gdal-1.3.1, grass61 from todays CVS.

Currently out of ideas...

Thanks for your help.

Best
  Stephan

--
GDF Hannover - Solutions for spatial data analysis and remote sensing
Hannover Office - Mengendamm 16d - D-30177 Hannover
Internet: www.gdf-hannover.de - Email: holl@gdf-hannover.de
Phone : ++49-(0)511.39088507 - Fax: ++49-(0)511.39088508

2

Hello Stephan
What is GK Zone 4 (DHDN)? It seems that the GDAL function OSRExportToProj4() is returning a PROJ.4 string with a missing "proj=" parameter, because it can't convert "GK Zone 4 (DHDN)" into a projection. GRASS is crashing because it assumes that there will always be a proj= value, not unreasonable I don't think! I could change it so it won't segfault but I think it would be better if the OSRExportToProj4() function returned an error code when it can't determine the projection.

Paul

On Wed, 10 May 2006, Stephan Holl wrote:

Dear lists,

[first posted to grass5, therefor reposted, since it did not make the
way to grass-dev]

I have a strange problem regarding Oracle spatial datasets.

My dataset has the following projection:

Extent: (4452550.890000, 5324953.370000) - (4479484.079834,
5345694.049805) Layer SRS WKT:
PROJCS["GK Zone 4 (DHDN)",
   GEOGCS[,
       DATUM[,
           SPHEROID["Bessel
1841",6377397.155,299.1528128],582.000000,105.000000,414.000000,-1.040000,-0.350000,3.080000,8.300000],
PRIMEM["Greenwich",0.000000], UNIT["Decimal
Degree",0.01745329251994330]], PROJECTION["Transverse Mercator"],
   PARAMETER["Scale_Factor",1.000000],
   PARAMETER["Central_Meridian",12.000000],
   PARAMETER["False_Easting",4500000.000000],
   UNIT["Meter",1.000000000000],
   AUTHORITY["Oracle","82032"]]
[Columns follow here]

Note that the datum-parameter is empty.

I can "export" the data into shp using ogr2ogr which results in a shape
with the following proj-information:

Feature Count: 10584
Extent: (4452550.890000, 5324953.370000) - (4479484.079834,
5345694.049805) Layer SRS WKT:
PROJCS["GK Zone 4 (DHDN)",
   GEOGCS[,
       DATUM["Mean_Sea_Level",
           SPHEROID["Bessel
1841",6377397.155,299.1528128],582.000000,105.000000,414.000000,-1.040000,-0.350000,3.080000,8.300000],
PRIMEM["Greenwich",0.000000], UNIT["Decimal
Degree",0.01745329251994330]], PROJECTION["Transverse Mercator"],
   PARAMETER["Scale_Factor",1.000000],
   PARAMETER["Central_Meridian",12.000000],
   PARAMETER["False_Easting",4500000.000000],
   UNIT["Meter",1.000000000000],
   AUTHORITY["Oracle","82032"]]

Here you can see that the Datum now contains "Mean_Sea_Level". When
inspecting the written .prj-file from the shape I cannot find any entry
in the datum-parameters like "Mean_Sea_Level".

Is this the normal behaviour? I am asking, because GRASS segfaults
when using v.in.ogr with location=newloc parameter enabled.

I am using gdal-1.3.1, grass61 from todays CVS.

Currently out of ideas...

Thanks for your help.

Best
  Stephan

--
GDF Hannover - Solutions for spatial data analysis and remote sensing
Hannover Office - Mengendamm 16d - D-30177 Hannover
Internet: www.gdf-hannover.de - Email: holl@gdf-hannover.de
Phone : ++49-(0)511.39088507 - Fax: ++49-(0)511.39088508

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

3

Hello Paul,

thanks for replying! I really appreaciate your comments (and
sollutions).

On Wed, 10 May 2006 14:54:49 +0100 (BST) Paul Kelly
<paul-grass@stjohnspoint.co.uk> wrote:

Hello Stephan
What is GK Zone 4 (DHDN)?

This is similar to EPSG:31468, from Oracle Spatial Datasets.

from my /usr/share/proj/epsg
# DHDN / Gauss-Kruger zone 4
<31468> +proj=tmerc +lat_0=0 +lon_0=12 +k=1.000000 +x_0=4500000 +y_0=0
+ellps=bessel +datum=potsdam +units=m +no_defs <>

or, from GRASS
lib/gis/datum.table
# Potsdam Rauenberg 1950 DHDN
potsdam "Deutsches_Hauptdreiecksnetz" bessel dx=606.0
dy=23.0 dz=413.0

It seems that the GDAL function
OSRExportToProj4() is returning a PROJ.4 string with a missing
"proj=" parameter, because it can't convert "GK Zone 4 (DHDN)" into a
projection.

OK, thanks for clarifying this. But apparently ogrinfo returns at least
correct projections parameters like
PRIMEM["Greenwich",0.000000], UNIT["Decimal
Degree",0.01745329251994330]], PROJECTION["Transverse Mercator"],
    PARAMETER["Scale_Factor",1.000000],
    PARAMETER["Central_Meridian",12.000000],
    PARAMETER["False_Easting",4500000.000000],
    UNIT["Meter",1.000000000000],

Could that be a problem with the different strings from Oracle here?

GRASS is crashing because it assumes that there will
always be a proj= value, not unreasonable I don't think! I could
change it so it won't segfault but I think it would be better if the
OSRExportToProj4() function returned an error code when it can't
determine the projection.

Yes, the latter would be the better choice afaik. Non-segfaults are
always appreciated :slight_smile: Would this be a big task and is it worth to
have such a short-term solution?

Thanks for your help

  Stephan

--
GDF Hannover - Solutions for spatial data analysis and remote sensing
Hannover Office - Mengendamm 16d - D-30177 Hannover
Internet: www.gdf-hannover.de - Email: holl@gdf-hannover.de
Phone : ++49-(0)511.39088507 - Fax: ++49-(0)511.39088508

4

Hello Stephan

On Wed, 10 May 2006, Stephan Holl wrote:

Hello Paul,

thanks for replying! I really appreaciate your comments (and
sollutions).

Apologies for not really keeping up with the list at all recently; this message just happened to catch my eye!

Hello Stephan
What is GK Zone 4 (DHDN)?

This is similar to EPSG:31468, from Oracle Spatial Datasets.

OK sorry I was confused asking that---that field isn't used for determining the projection; it is just meant to be human readable AFAIK and it wasn't the problem.

It seems that the GDAL function
OSRExportToProj4() is returning a PROJ.4 string with a missing
"proj=" parameter, because it can't convert "GK Zone 4 (DHDN)" into a
projection.

OK, thanks for clarifying this. But apparently ogrinfo returns at least
correct projections parameters like
PRIMEM["Greenwich",0.000000], UNIT["Decimal
Degree",0.01745329251994330]], PROJECTION["Transverse Mercator"],
   PARAMETER["Scale_Factor",1.000000],
   PARAMETER["Central_Meridian",12.000000],
   PARAMETER["False_Easting",4500000.000000],
   UNIT["Meter",1.000000000000],

Could that be a problem with the different strings from Oracle here?

Yes. I think the problem is the missing underscore _ between Transverse and Mercator. Seems simple but confuses the OGR function and I'm really not sure how best to handle it.

GRASS is crashing because it assumes that there will
always be a proj= value, not unreasonable I don't think! I could
change it so it won't segfault but I think it would be better if the
OSRExportToProj4() function returned an error code when it can't
determine the projection.

Yes, the latter would be the better choice afaik. Non-segfaults are
always appreciated :slight_smile: Would this be a big task and is it worth to
have such a short-term solution?

OK I've changed it now to print a warning if the projection name is missing rather than giving a segfault (however the resulting projection parameters will not be much use!).

Best regards

Paul

5

Hello Paul,

On Wed, 10 May 2006 16:12:30 +0100 (BST) Paul Kelly
<paul-grass@stjohnspoint.co.uk> wrote:

Hello Stephan

On Wed, 10 May 2006, Stephan Holl wrote:

> Hello Paul,
>
> thanks for replying! I really appreaciate your comments (and
> sollutions).

Apologies for not really keeping up with the list at all recently;
this message just happened to catch my eye!

>> Hello Stephan
>> What is GK Zone 4 (DHDN)?
>
> This is similar to EPSG:31468, from Oracle Spatial Datasets.

OK sorry I was confused asking that---that field isn't used for
determining the projection; it is just meant to be human readable
AFAIK and it wasn't the problem.

OK.

>> It seems that the GDAL function
>> OSRExportToProj4() is returning a PROJ.4 string with a missing
>> "proj=" parameter, because it can't convert "GK Zone 4 (DHDN)"
>> into a projection.
>
> OK, thanks for clarifying this. But apparently ogrinfo returns at
> least correct projections parameters like
> PRIMEM["Greenwich",0.000000], UNIT["Decimal
> Degree",0.01745329251994330]], PROJECTION["Transverse Mercator"],
> PARAMETER["Scale_Factor",1.000000],
> PARAMETER["Central_Meridian",12.000000],
> PARAMETER["False_Easting",4500000.000000],
> UNIT["Meter",1.000000000000],
>
> Could that be a problem with the different strings from Oracle here?

Yes. I think the problem is the missing underscore _ between
Transverse and Mercator. Seems simple but confuses the OGR function
and I'm really not sure how best to handle it.

I see.

>> GRASS is crashing because it assumes that there will
>> always be a proj= value, not unreasonable I don't think! I could
>> change it so it won't segfault but I think it would be better if
>> the OSRExportToProj4() function returned an error code when it
>> can't determine the projection.
>
> Yes, the latter would be the better choice afaik. Non-segfaults are
> always appreciated :slight_smile: Would this be a big task and is it worth to
> have such a short-term solution?

OK I've changed it now to print a warning if the projection name is
missing rather than giving a segfault (however the resulting
projection parameters will not be much use!).

After updating from CVS today I recompiled and tested your changes.
However, the program is not segfaulting anymore.

But, it does not import any other projected dataset anymore unless I
specify -o which mostly is unintended for projected data.

Spearfish.dataset:
# exporting roads in tmp-dir
v.out.ogr in=roads type=line dsn=/tmp olayer=spear_roads

# verifying exported dataset
ogrinfo -al -so /tmp/spear_roads.shp
INFO: Open of `/tmp/spear_roads.shp'
using driver `ESRI Shapefile' successful.

Layer name: spear_roads
Geometry: Line String
Feature Count: 825
Extent: (589434.856469, 4914006.337837) - (609527.210215,
4928063.398015) Layer SRS WKT:
PROJCS["UTM Zone 13, Northern Hemisphere",
    GEOGCS["clark66",
        DATUM["North_American_Datum_1927",
            SPHEROID["clark66",6378206.4,294.9786982]],
        PRIMEM["Greenwich",0],
        UNIT["Degree",0.017453292519943295]],
    PROJECTION["Transverse_Mercator"],
    PARAMETER["latitude_of_origin",0],
    PARAMETER["central_meridian",-105],
    PARAMETER["scale_factor",0.9996],
    PARAMETER["false_easting",500000],
    PARAMETER["false_northing",0],
    UNIT["Meter",1]]
cat: Real (11.0)
label: String (80.0)

Seems OK so far.

# Reimporting
v.in.ogr dsn=/tmp layer=spear_roads out=test2222
ERROR: Projection of dataset does not appear to match current location.

       LOCATION PROJ_INFO is:
       name: UTM
       datum: nad27
       nadgrids: conus
       proj: utm
       ellps: clark66
       a: 6378206.4000000004
       es: 0.0067686580
       f: 294.9786982000
       zone: 13

       cellhd.proj = 0 (unreferenced/unknown)
                   ^^^^^^^^^ Wrong!

?!

I am using proj-4.5b2 with nadgrids compiled in
grass61-cvs from today
gdal-1.3.2

So the latest EPSG-changes committed to proj, gdal and grass should be
there.

Can you reproduce this?

Anyway, thanks for helping so fast.

Best
  
  Stephan

--
GDF Hannover - Solutions for spatial data analysis and remote sensing
Hannover Office - Mengendamm 16d - D-30177 Hannover
Internet: www.gdf-hannover.de - Email: holl@gdf-hannover.de
Phone : ++49-(0)511.39088507 - Fax: ++49-(0)511.39088508

6

Hello Stephan

On Thu, 11 May 2006, Stephan Holl wrote:

But, it does not import any other projected dataset anymore unless I
specify -o which mostly is unintended for projected data.

[...]

# Reimporting
v.in.ogr dsn=/tmp layer=spear_roads out=test2222
ERROR: Projection of dataset does not appear to match current location.

      LOCATION PROJ_INFO is:
      name: UTM
      datum: nad27
      nadgrids: conus
      proj: utm
      ellps: clark66
      a: 6378206.4000000004
      es: 0.0067686580
      f: 294.9786982000
      zone: 13

      cellhd.proj = 0 (unreferenced/unknown)
                  ^^^^^^^^^ Wrong!

Hmm I don't see how the change I made could affect that at all. What does
g.region -p
say?

I should also say that the projection comparison code is "just there", I don't like it, don't think it is a good way of testing things nor very robust/comprehensive, but there is no better way of doing it so it stays there!

Paul

7

Hello Paul,

On Thu, 11 May 2006 12:35:46 +0100 (BST) Paul Kelly
<paul-grass@stjohnspoint.co.uk> wrote:

Hello Stephan

On Thu, 11 May 2006, Stephan Holl wrote:

> But, it does not import any other projected dataset anymore unless I
> specify -o which mostly is unintended for projected data.
>
[...]
> # Reimporting
> v.in.ogr dsn=/tmp layer=spear_roads out=test2222
> ERROR: Projection of dataset does not appear to match current
> location.
>
> LOCATION PROJ_INFO is:
> name: UTM
> datum: nad27
> nadgrids: conus
> proj: utm
> ellps: clark66
> a: 6378206.4000000004
> es: 0.0067686580
> f: 294.9786982000
> zone: 13
>
> cellhd.proj = 0 (unreferenced/unknown)
> ^^^^^^^^^ Wrong!

Hmm I don't see how the change I made could affect that at all.

I don`t understand this at all!

What
does g.region -p
say?

Thats what it says...
g.region -p
projection: 1 (UTM)
zone: 13
datum: nad27
ellipsoid: clark66
north: 4928010
south: 4913700
west: 589980
east: 609000
nsres: 30
ewres: 30
rows: 477
cols: 634

Strange. Everything should be right.

I should also say that the projection comparison code is "just
there", I don't like it, don't think it is a good way of testing
things nor very robust/comprehensive, but there is no better way of
doing it so it stays there!

Yes, no problem at all.

Ahhh, I found out:

# show layers in folders
v.in.ogr -l dsn=/tmp layer=spear_roads out=test5
Data source contains 3 layers:
spear_roads, flst_gef, NSG_Beispie
^^^ ^^^ ^^^
EPSG:26713 EPSG:31467 EPSG:31467

# now import
v.in.ogr dsn=/tmp layer=spear_roads out=test5
ERROR: Projection of dataset does not appear to match current location.

       LOCATION PROJ_INFO is:
       name: UTM
       datum: nad27
       nadgrids: conus
       proj: utm
       ellps: clark66
       a: 6378206.4000000004
       es: 0.0067686580
       f: 294.9786982000
       zone: 13

       cellhd.proj = 0 (unreferenced/unknown)

# different syntax
v.in.ogr dsn=/tmp/spear_roads.shp out=test5

A datum name nad27 (North_American_Datum_1927) was specified without
transformation parameters. WARNING: Non-interactive mode: the GRASS
default for nad27 is towgs84=-22.000,157.000,176.000.
Projection of input dataset and current location appear to match.
Proceeding with import...
[successfull import]

The first syntax fails, if the datasource (the folders the shapes are
in) shapefiles with different projections reside in.

No problem, if you export heaps of spearfish-shapes, but put another
shape with e.g. EPSG:4326 inside and you will fail to import the
dataset with the second syntax.

This seems to be a bug (if anybody can confirm of course)

Best
  Stephan

--
GDF Hannover - Solutions for spatial data analysis and remote sensing
Hannover Office - Mengendamm 16d - D-30177 Hannover
Internet: www.gdf-hannover.de - Email: holl@gdf-hannover.de
Phone : ++49-(0)511.39088507 - Fax: ++49-(0)511.39088508

8

Hello again Stephan

On Thu, 11 May 2006, Stephan Holl wrote:

Ahhh, I found out:

# show layers in folders
v.in.ogr -l dsn=/tmp layer=spear_roads out=test5
Data source contains 3 layers:
spear_roads, flst_gef, NSG_Beispie
^^^ ^^^ ^^^
EPSG:26713 EPSG:31467 EPSG:31467

[...]

The first syntax fails, if the datasource (the folders the shapes are
in) shapefiles with different projections reside in.

No problem, if you export heaps of spearfish-shapes, but put another
shape with e.g. EPSG:4326 inside and you will fail to import the
dataset with the second syntax.

This seems to be a bug (if anybody can confirm of course)

Good detective work.
I agree; I had a little look at the logic in v.in.ogr and it seems a little bit confused (but of course I might be confused too!). As far as I can see the spatial subregion checking (used only if the spatial= option is used) and projection checking use the *last* layer found to base their checks on.

The way I saw it before was that all layers in the dataset should have the same projection so that should be OK. But I see now from your example that that is not always the case. Please try the attached patch below (I haven't tested; I don't really use v.in.ogr) which should cause the projection checks to be based on the first layer *actually imported* (i.e. not just the first or last one found in the dataset).

I would be grateful if you could let me know if this works. However, as far as I can see, the spatial subregion code still seems to assume that only one layer is being imported---can anybody confirm this?

Paul

Index: main.c

RCS file: /grassrepository/grass6/vector/v.in.ogr/main.c,v
retrieving revision 1.62
diff -u -r1.62 main.c
--- main.c 4 Apr 2006 18:20:19 -0000 1.62
+++ main.c 11 May 2006 14:00:11 -0000
@@ -298,6 +298,9 @@
             layers[i] = i;
      }

+ /* Get first imported layer to use for extents and projection check */
+ Ogr_layer = OGR_DS_GetLayer( Ogr_ds, layers[0] );
+
      if ( spat_opt->answer ) {
          /* See as reference: gdal/ogr/ogr_capi_test.c */

9

Hello again Paul,

On Thu, 11 May 2006 15:05:30 +0100 (BST) Paul Kelly
<paul-grass@stjohnspoint.co.uk> wrote:

Hello again Stephan

On Thu, 11 May 2006, Stephan Holl wrote:

> Ahhh, I found out:
>
> # show layers in folders
> v.in.ogr -l dsn=/tmp layer=spear_roads out=test5
> Data source contains 3 layers:
> spear_roads, flst_gef, NSG_Beispie
> ^^^ ^^^ ^^^
> EPSG:26713 EPSG:31467 EPSG:31467
>
[...]
> The first syntax fails, if the datasource (the folders the shapes
> are in) shapefiles with different projections reside in.
>
> No problem, if you export heaps of spearfish-shapes, but put another
> shape with e.g. EPSG:4326 inside and you will fail to import the
> dataset with the second syntax.
>
> This seems to be a bug (if anybody can confirm of course)

Good detective work.
I agree; I had a little look at the logic in v.in.ogr and it seems a
little bit confused (but of course I might be confused too!). As far
as I can see the spatial subregion checking (used only if the
spatial= option is used) and projection checking use the *last* layer
found to base their checks on.

I see, so then the found reaction make sense.

The way I saw it before was that all layers in the dataset should
have the same projection so that should be OK. But I see now from
your example that that is not always the case.

...especially not when you are using another database like PostGIS or
Oracle which have ususally more layers with different projections in.

Please try the
attached patch below (I haven't tested; I don't really use v.in.ogr)
which should cause the projection checks to be based on the first
layer *actually imported* (i.e. not just the first or last one found
in the dataset).

Well, yes, this eliminates my problem. Now both synatxes work for
shapes even when a folder contains differntly projected shapefiles.

Good work!

I would be grateful if you could let me know if this works. However,
as far as I can see, the spatial subregion code still seems to assume
that only one layer is being imported---can anybody confirm this?

Cool, Paul. This works for me now!

Perhaps anybody can confirm this as well and commit it to CVS?

Best
  Stephan

Index: main.c

RCS file: /grassrepository/grass6/vector/v.in.ogr/main.c,v
retrieving revision 1.62
diff -u -r1.62 main.c
--- main.c 4 Apr 2006 18:20:19 -0000 1.62
+++ main.c 11 May 2006 14:00:11 -0000
@@ -298,6 +298,9 @@
             layers[i] = i;
      }

+ /* Get first imported layer to use for extents and projection
check */
+ Ogr_layer = OGR_DS_GetLayer( Ogr_ds, layers[0] );
+
      if ( spat_opt->answer ) {
          /* See as reference: gdal/ogr/ogr_capi_test.c */

--
GDF Hannover - Solutions for spatial data analysis and remote sensing
Hannover Office - Mengendamm 16d - D-30177 Hannover
Internet: www.gdf-hannover.de - Email: holl@gdf-hannover.de
Phone : ++49-(0)511.39088507 - Fax: ++49-(0)511.39088508

10

On Thu, 11 May 2006, Stephan Holl wrote:

I would be grateful if you could let me know if this works. However,
as far as I can see, the spatial subregion code still seems to assume
that only one layer is being imported---can anybody confirm this?

Cool, Paul. This works for me now!

Perhaps anybody can confirm this as well and commit it to CVS?

OK well I can't see any problems with it so I have committed. Perhaps it would be an idea to exit with an error if the spatial= functionality is being used when more than one layer is being imported, but certainly it should also be working better too now I think as it would have also been potentially using the wrong layer before.

Paul

11

Hello Paul,

On Thu, 11 May 2006 15:55:12 +0100 (BST) Paul Kelly
<paul-grass@stjohnspoint.co.uk> wrote:

On Thu, 11 May 2006, Stephan Holl wrote:

>> I would be grateful if you could let me know if this works.
>> However, as far as I can see, the spatial subregion code still
>> seems to assume that only one layer is being imported---can
>> anybody confirm this?
>
> Cool, Paul. This works for me now!
>
> Perhaps anybody can confirm this as well and commit it to CVS?

OK well I can't see any problems with it so I have committed. Perhaps
it would be an idea to exit with an error if the spatial=
functionality is being used when more than one layer is being
imported, but certainly it should also be working better too now I
think as it would have also been potentially using the wrong layer
before.

yes, good point. Is it easy to implement?

Thanks for your help again.

One short question regarding the projection-check-overriding (-o): Does
this prevent GRASS using any projection-related stuff?

Best
  Stephan

--
GDF Hannover - Solutions for spatial data analysis and remote sensing
Hannover Office - Mengendamm 16d - D-30177 Hannover
Internet: www.gdf-hannover.de - Email: holl@gdf-hannover.de
Phone : ++49-(0)511.39088507 - Fax: ++49-(0)511.39088508

12

On Fri, 12 May 2006, Stephan Holl wrote:

On Thu, 11 May 2006 15:55:12 +0100 (BST) Paul Kelly
<paul-grass@stjohnspoint.co.uk> wrote:

OK well I can't see any problems with it so I have committed. Perhaps
it would be an idea to exit with an error if the spatial=
functionality is being used when more than one layer is being
imported, but certainly it should also be working better too now I
think as it would have also been potentially using the wrong layer
before.

yes, good point. Is it easy to implement?

Should be. Something like
if ( spat_opt->answer ) {
     if ( nlayers > 1 )
         G_fatal_error( "..." );

BUT.. I don't know if this is how it works or not. I don't even know if it's a problem the way it is currently, and and even if it is, perhaps it's possible to modify the code to apply the spatial filter to all layers rather than just exiting. I'm just pointing out that it probably needs to be checked at some stage. Not planning to change anything now.

One short question regarding the projection-check-overriding (-o): Does
this prevent GRASS using any projection-related stuff?

Not sure what you mean here---as long as the projection for the location the map is being imported into is set up correctly then all should be fine.

Paul

13

Hello Paul,

On Mon, 15 May 2006 12:23:43 +0100 (BST) Paul Kelly
<paul-grass@stjohnspoint.co.uk> wrote:

On Fri, 12 May 2006, Stephan Holl wrote:

> On Thu, 11 May 2006 15:55:12 +0100 (BST) Paul Kelly
> <paul-grass@stjohnspoint.co.uk> wrote:
>>
>> OK well I can't see any problems with it so I have committed.
>> Perhaps it would be an idea to exit with an error if the spatial=
>> functionality is being used when more than one layer is being
>> imported, but certainly it should also be working better too now I
>> think as it would have also been potentially using the wrong layer
>> before.
>
> yes, good point. Is it easy to implement?

Should be. Something like
if ( spat_opt->answer ) {
     if ( nlayers > 1 )
         G_fatal_error( "..." );

BUT.. I don't know if this is how it works or not. I don't even know
if it's a problem the way it is currently, and and even if it is,
perhaps it's possible to modify the code to apply the spatial filter
to all layers rather than just exiting. I'm just pointing out that it
probably needs to be checked at some stage. Not planning to change
anything now.

OK. I have used the spatial-switch successfully after your fix and the
result was cut cirrect. I could not check if the projection whould have
been checked correct, because I had to overwrite projection-check.
This is currently needed because of the "Transverse Mercator"
string-problem (missing underscore) in my data...

> One short question regarding the projection-check-overriding (-o):
> Does this prevent GRASS using any projection-related stuff?

Not sure what you mean here---as long as the projection for the
location the map is being imported into is set up correctly then all
should be fine.

Yes, that is what I mean. I had received some segfaults during -o
switch, but apparently this was because a missing make distclean.

Best
  Stephan

--
GDF Hannover - Solutions for spatial data analysis and remote sensing
Hannover Office - Mengendamm 16d - D-30177 Hannover
Internet: www.gdf-hannover.de - Email: holl@gdf-hannover.de
Phone : ++49-(0)511.39088507 - Fax: ++49-(0)511.39088508