headers
Hamish | 1 Jul 2004 05:56
X-Face
Picon
Favicon

Re: Re: [Gdal-dev] ERDAS/IMG driver error for NULL values

> I compiled GDAL with the patches from Radim for new raster support
> also in QGIS.

I'm just wondering if the brand new 1.2.1 version of GDAL includes
what's needed for displaying GRASS rasters in QGIS? What about PostGIS
support?

see http://article.gmane.org/gmane.comp.gis.grass.devel/3999

Hamish
Permalink | Reply | 1 comment |
headers
Radim Blazek | 1 Jul 2004 09:52
Picon

Re: Re: [Gdal-dev] ERDAS/IMG driver error for NULL values

On Thursday 01 July 2004 05:56, Hamish wrote:
> > I compiled GDAL with the patches from Radim for new raster support
> > also in QGIS.
>
> I'm just wondering if the brand new 1.2.1 version of GDAL includes
> what's needed for displaying GRASS rasters in QGIS? What about PostGIS
> support?

The patches for 5.7 are not yet in GDAL CVS, it is also possible 
to use libgrass.

Radim
Permalink | Reply | 0 comments |
headers
Radim Blazek | 1 Jul 2004 12:31
Picon

Re: filtering vector areas

> On Sunday 20 June 2004 17:38, Otto Dassau wrote:
> > Then there is the implemented sides option for v.to.db by Radim. I tried
> > this but I don't understand how to use this option because I don't know
> > what this option is for - sorry :-(
> >
> >  sides - categories of areas on the left and right side of the boundary,
> > 'qfield' is used for area category.
> >
> > Radim, could you please give an example what this option os for? Maybe
> > this is a solution but I don't see it.
>
> You can identify the boundaries which have to be removed from the vector in
> SQL if you have: area type, area size, boundary length, area on the
> left/right side of the boundary. Whithout 'sides' option in v.to.db, it was
> impossible to get area on the left/right side of the boundary.

I added also new tool=rmarea to v.clean, which removes small areas.
If you need to keep small areas of certain category, you can do
v.extract; v.clean tool=rmarea; v.patch; v.clean tool=rmdupl

Previous suggestion (v.to.db + SQL) is still valid however.

Radim
Permalink | Reply | 0 comments |
headers
Richard Greenwood | 1 Jul 2004 15:25

Re: Re: GRASS 5.3 windows

I never saw this message show up on Grass5 so I am sending it again. 
Sorry if you receive this twice.

Glynn Clements wrote:

> Markus Neteler wrote:
> 
> 
>>>>>Just curious: Did you ever try
>>>>>make strip
>>>>>to make smaller binaries? Or are they already stripped?
>>>>
>>>>I ran 'make strip' and then 'make bindist' The binaries are almost 
>>>>identical in size to the binaries without 'make strip'. This is logical 
>>>>given that I did not build with debugging information, but it does not 
>>>>explain why the 5.3 binaries are so large.
>>>>   5.0 ~35MB
>>>>   5.3 ~67MB
>>>>   5.7 ~27MB
>>>>All built with CFLAGS="-O2"
>>>
>>>Richard: Perhaps you could post the configure parameters.
>>
>>does anyone have an idea?
> 
> 
> The obvious first guess is static libraries. If one of the core
> libraries (e.g. libgis) is pulling in an extra static library, that
> could make a big difference.
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Glynn Clements | 2 Jul 2004 00:25
Favicon

Re: Re: GRASS 5.3 windows


Richard Greenwood wrote:

> I think I see my mistake: 'make strip' strips from the files in the
> dist.i686-pc-cygwin directory. But 'make bindist' uses the files from
> the actual installation directory e.g.  /usr/local/grass53
> 
> Is this assumption correct?

Yes.

> And if so, why does bindist use the files
> from the installation directory rather than the dist.i686-pc-cygwin
> directory?

I don't know.

> And why does 5.3 seem to include debugging symbols when 5.0 and 5.7 do
> not? In all 3 cases I am configuring with:
>    CFLAGS="-O2"
>    LDFLAGS="-s -L/usr/local/lib -L/usr/X11R6/lib"

I have no idea. Any LDFLAGS settings should be honoured. Does the "-s"
actually show up in the link commands? Is it in the value of
LINK_FLAGS in src/CMD/head/head.<arch> (gmake build system) or
mk/vars.mk (alternate build system)?

--

-- 
Glynn Clements <glynn.clements <at> virgin.net>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hamish | 2 Jul 2004 11:17
X-Face
Picon
Favicon

GRASS 5.7: g.remove bug

If you use v.external to connect to a shape file, then remove the shape
file it no longer works. That's ok.

When you try to remove the zombie vector file with 'g.remove vect=foo'
it says:

REMOVE [foo]
ERROR: Cannot open layer 'foo_shp'

and it doesn't remove anything....

thanks,
Hamish
Permalink | Reply | 1 comment |
headers
Radim Blazek | 2 Jul 2004 19:30
Picon

v.univar

I have written v.univar. I am not sure how to calculate statistics 
for lines and areas, does the code below make sense?
Radim

Lines:
   for each line {
        sum += line_length * variable;
        sumsq += line_length * variable * variable;
        total_length += line_length;
   }
   mean = sum / total_lenght;
   population_variance = (sumsq - sum*sum/total_length)/total_length;
   population_stdev = sqrt(population_variance);

Areas: 
   for each area {
        sum += area_size * variable;
        sumsq += areas_size * variable * variable;
        total_size += area_size;
   }
   mean = sum / total_size;
   population_variance = (sumsq - sum*sum/total_size)/total_size;
   population_stdev = sqrt(population_variance);
Permalink | Reply | 0 comments |
headers
Roger Bivand | 2 Jul 2004 19:52
Picon

Re: v.univar

On Fri, 2 Jul 2004, Radim Blazek wrote:

> I have written v.univar. I am not sure how to calculate statistics 
> for lines and areas, does the code below make sense?

Briefly, no. You are calculating weighted means, weighting by line length
or area surface size. I think it would be better to treat each line or
area as a discrete, unweighted, unit unless some reason to the contrary is
given, just like points/sites. It is probably more important to handle
missing data gracefully than weight the means or other statistics, I
think. There may be reasons to weight sometimes, but most often I see
ratios or rates of two variables, rather than of a single variable and
length or area.

Roger

> Radim
> 
> Lines:
>    for each line {
>         sum += line_length * variable;
>         sumsq += line_length * variable * variable;
>         total_length += line_length;
>    }
>    mean = sum / total_lenght;
>    population_variance = (sumsq - sum*sum/total_length)/total_length;
>    population_stdev = sqrt(population_variance);
> 
> Areas: 
>    for each area {
(Continue reading)

Permalink | Reply | 2 comments |
headers
Markus Neteler | 2 Jul 2004 23:38
Picon

Presence of NULL data in raster maps?

Hi,

there seems to be missing a function which reports the presence 
of NULL data in a raster map. This functions is needed for 
interfacing GRASS to GDAL, especially for 8 bit data.
At time the entire map must be scanned, right? This
can become pretty time consuming.

Is it sufficient to test the presence of the 'null' file 
within this potential function? A bit dirty, but otherwise the
cellhd file needed an addition (null: true or whatever).

Suggestions (or code)?

Markus
Permalink | Reply | 5 comments |
headers
Markus Neteler | 2 Jul 2004 23:40
Picon

Raster API names suggestion

Hi again,

to improve the GRASS API name convention, I would like to 
suggest to rename the raster functions from G_ to Rast_.
A recursive find/sed should easily do the job.

Markus
Permalink | Reply | 5 comments |

Gmane