[GRASS-user] Help needed in identifying the DEM / DTED classes used in grass

[Anand V]

Hi Everybody,

I am new to GRASS and i am trying to load the DTED data map in my visual c++
application. Actually i am trying to load dt2 data directly in my visual c++
application, i do not want to run GRASS as separate process with my
application, In GRASS source code i need to identify the classes used to
load a DEM or DTED data so i can directly try those with my visual c++
application.

Anybody know the classes and header files used in GRASS to load the dted
data

I tried and i am not able to identify.

Please give ur suggestions and help me out

Thanks in advance

ANAND V
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Re: Exporting attributes to GMT ASCII format using v.out.ogr

[Hamish]

Hermann wrote:
> A plain: v.out.ogr RBD_F1v3 format=GMT dsn=RBD_F1v3.gmt
> results into:
> 
> # FEATURE_DATA
> > 
> # @D||
> 
> 
> but  v.out.ogr RBD_F1v3 format=GMT type=area dsn=RBD_F1v3.gmt gives:
> 
> # FEATURE_DATA
> > 
> # @D1|"Fleuves et cours d'eau cotiers de la Guyane"|fr|FR|"Guyana
> (French)"|83892.657134|W1001|FRW1001|FRK||"North Western Atlantic 
> Ocean"|"Open 
> Ocean"||W1000|FRW1000|W1|N|Y|2005-06-03|FR1||2008-02-26|ASB|136|FRK|1660787.48438|83892657133.7
> 
> 
> Hope this helps, Hermann

I think it does, the default for v.out.ogr is type=line,boundary

tip added in  http://grass.osgeo.org/wiki/GMT#Vector


I would ask if it acts any differently in latest grass 6.5 or 7 svn builds? 
(6.5 change may be reverted as it may break
backwards compatibility / expected behaviour)


Hamish




___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Very high resolution topographic map of Europe: need help and advices: UPDATE

[Felix Schalck]

Hi,

I got news from the GDAL mailing list, where I posted a similar
question about that strange format I downloaded on the CCM  JRC web
page. It seems to be the new ArcGIS file geodatabase format introduced
by ESRI in ArcGIS 9.2, according to Jason Roberts and Frank Warmerdam.
The important thing here is that it is a different database format
(from .mdb or argis personal database), entirely proprietary which
cannot, as of september 2009, be read by any OGR driver. So we took
steps to contact the author/distributor of CCM data in order to have
the set distributed in another format. More on this to follow.

Regards,

Felix
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Grass installation - Linux

[Facundo Muñoz]

I think it depends on what Linux distro you have.

I use Ubuntu, and have recently installed Grass from scratch from 
https://launchpad.net/~ubuntugis/+archive/ubuntugis-unstable

without trouble.
It is a repository with a coherent bundle of GIS soft and libs that is 
tested to work well together.


Hope it helps.
  facu.-

PS: Make sure you perform a clean-up before re-installing .

Cverckova, Lubica escribió:


Good Morning,

 

We are having trouble completing GRASS installation on Linux. My 
questions are:


 

1. As I am attempting to install gdal, I am finding it need more 
upgraded libraries, now there are other apps which may be using the 
same libraries, like libc, libc++ and so on,


 

2. Does anyone know if there is kind of bundle available somewhere 
which has its own libraries and its own small world, rather than using 
system wide libraries, My search did not come with much output,


 


I appreciate your response. Thank you.

 


Lubica

 

 

 


**Lubica Cverckova**

**GIS Specialist**

 


Division of Asset Information Strategies

Hatch Mott MacDonald

27 Bleeker Street

Millburn, NJ 07041

Tel: (973) 379 - 8749

Fax: (973) 379 - 8970

www.hatchmott.com 

 



__
Attention:
This e-mail and any files transmitted with it from Hatch Mott 
MacDonald are confidential and intended solely for use of the 
individual or entity to whom they are addressed. If you have received 
this e-mail in error please immediately notify the sender.

__


___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
  
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Re: Exporting attributes to GMT ASCII format using v.out.ogr

[Hermann Peifer]

Hamish wrote:

Eric:

I'm using v.out.ogr to export GRASS vectors to GMT format.
The geometry exports fine, but the attributes don't seem
to be in the GMT file after the export finishes. I can see
the attribute column names in the GMT header portion of
the file, but all I get in the data columns are the x
and y, followed by a zero in the third column. 


Any special CREATEOPT parameters that need to be passed? I
checked on the OGR website and there wasn't any hints about
it; same with the v.out.ogr manual (GMT format isn't even
mentioned there).



no new help to offer, but if you find something out it would be
good to add it to the wiki page:

   http://grass.osgeo.org/wiki/GMT#Vector


if nothing on the format page at the GDAL/OGR website, for CREATEOPT
you might have to go exploring in the OGR source code.




A plain: v.out.ogr RBD_F1v3 format=GMT dsn=RBD_F1v3.gmt results into:

# FEATURE_DATA



# @D||


but  v.out.ogr RBD_F1v3 format=GMT type=area dsn=RBD_F1v3.gmt gives:

# FEATURE_DATA



# @D1|"Fleuves et cours d'eau cotiers de la Guyane"|fr|FR|"Guyana 
(French)"|83892.657134|W1001|FRW1001|FRK||"North Western Atlantic Ocean"|"Open 
Ocean"||W1000|FRW1000|W1|N|Y|2005-06-03|FR1||2008-02-26|ASB|136|FRK|1660787.48438|83892657133.7


Hope this helps, Hermann
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Grass installation - Linux

[Cverckova, Lubica]

Good Morning,

 

We are having trouble completing GRASS installation on Linux. My
questions are:

 

1. As I am attempting to install gdal, I am finding it need more
upgraded libraries, now there are other apps which may be using the same
libraries, like libc, libc++ and so on,

 

2. Does anyone know if there is kind of bundle available somewhere which
has its own libraries and its own small world, rather than using system
wide libraries, My search did not come with much output,

 

I appreciate your response. Thank you.

 

Lubica

 

 

 

Lubica Cverckova

GIS Specialist

 

Division of Asset Information Strategies 

Hatch Mott MacDonald

27 Bleeker Street

Millburn, NJ 07041

Tel: (973) 379 - 8749

Fax: (973) 379 - 8970

www.hatchmott.com 

 


__
Attention:
This e-mail and any files transmitted with it from Hatch Mott MacDonald are 
confidential and intended solely for use of the individual or entity to whom 
they are addressed. If you have received this e-mail in error please 
immediately notify the sender.
_
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] quantile/percentile

[Laura Poggio]

Thank you!
 r.series is working fine. I am now trying to solve the problem of the limit
for the number of files within my linux distribution.
It is rather fast, much faster then using R. However my rasters are rather
small (15000 cells), then I do not know how it would behave with a much
larger file.

Thank you again

Laura

2009/9/17 Glynn Clements 

>
> Laura Poggio wrote:
>
> > I would need to calculate the resulting percentile map from a large
> number
> > of maps (>1), obtaining the values for 5 and 95 percentile for each
> > pixel. Is there any function in GRASS?
>
> Recent versions of r.series can calculate arbitrary quantiles.
>
> You may have to make some configuration changes in order to allow a
> single process to have >1 open file descriptors (for Linux, check
> /etc/security/limits.conf).
>
> Memory shouldn't be an issue, as r.series only needs to hold one row
> from each map at a time.
>
> This won't be particularly fast, as r.series method=quantile sorts all
> of the values then picks out the requested quantile. And if you
> calculate multiple quantiles, it will sort the values once for each
> quantile.
>
> CC to grass-dev:
>
> The duplicate sorting can be gotten around in a several ways:
>
> 1. Have the sorting routine first check for an already sorted list.
>
> 2. Add a global variable to lib/stats to indicate that the data is
> already sorted.
>
> 3. Add yet another parameter to the stats functions to indicate that
> the data is sorted.
>
> 4. Use the closure parameter to indicate that the data is sorted (for
> c_quant(), this would mean that it would need to point to a structure
> containing both the quantile and the sorted flag).
>
> #1 is inefficient, #2 is a bit of a hack, #3 adds another parameter
> which most functions won't use (only diversity, median, mode,
> quantiles need sorted data), #4 is awkward to use.
>
> The inefficient quantile algorithm can be replaced (or augmented) with
> the more efficient (and more complex) one used by r.quantile and
> r.statistics3. But is it worth the effort and complexity?
>
> Essentially, it only matters if the number of maps is large enough
> that the qsort() dominates. For a few maps, the setup overhead of the
> more complex algorithm will make it slower. For an intermediate
> number, the speed gain may be small compared to other overheads. It's
> worth it for calculating quantiles over millions of values (although
> the primary motivation was to avoid having to store all values in
> memory), but I don't know if it's worth it for 10,000 values.
>
> --
> Glynn Clements 
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user