Land Use Land Cover Data

[Ricardo T. Costa]

Dear members,

first of all I'll introduce myself, my name is Ricardo T. Costa and
I'm currently working with the CALMET/CALPUFF system at
GECOsistema.eu, although I didn't manage to attend the latest European
TRC course at Pisa I've followed it attentively through the
representation of GECOsistema s.r.l. I want to thank and congratulate
you for this discussion group, for it may be an important discussion
platform.

So if I may, I would like in this topic to discuss my latest issues
regarding the Land Use Land Cover in the CALMET/CALPUFF System and it
goes as it follows:

I've been trying to input the European Corine Land Cover into to the
model through CTGCOMP, in order to get a better representation
(resolution) of the Land Use in my study area. So, I've reformatted
manually (header, plus grid rows) has best has I could (reclassifying
the CLC codes to USGS and tried to follow the description provided by
USGS) a file to match the Composite Theme Grid (CTG) data format of
the USGS LULC. I've manage to get an output, with the correct desired
grid, grid domain and digital shoreline, but on the cells
corresponding to LULC I've got a major replacement of values with the
reference value for marine land use type 55 plus some (few)
intercalated columns with LULC codes.

I think I may have a problem in the formatting of the CTG header or
grid, although it computes. Does anyone ever tried to do this, is
there a easier way to get Corine Land Cover data into the GEO.DAT
file?

Thank you in advance

[Jana Krajcovicova]

Dear Ricardo,

I use CORINE data for CALPUFF. Here is the procedure:

I have imported the CORINE geotiff raster file for the whole Europe into a GRASS GIS location. The CORINE geotiff has a native resolution of 100m, if I remember correctly. There, in GRASS, I reclassified the categories to match the USGS convention (there is a function r.reclass in GRASS for that ). Every time I need to define a new domain, it is very easy to specify the region and resolution and use another convenient function of GRASS - r.resamp.stats - which uses a statistical measure, e.g., mode, for resampling categorical data into a coarser grid and export result into .xyz ASCII file.
I wrote a perl script which takes xyz ascii file of landuse, terrain, plus other necessary parameters and produces a geofile. I completely skip CTGCOMP, because I had problems with it in past.

I can provide the script, if you are interested. GRASS GIS is an open source software.

Regards,

Jana

--
******************************************
Jana Krajčovičová, PhD.
Department of Air Quality
Slovak Hydrometeorological Institute
Jeséniova 17
831 01 Bratislava

jana.kra...@shmu.sk

[Ricardo T. Costa]

Hi Jana,

thanks for the reply, if you could be so kind to provide me the GRASS
script so I can try to work around this issue I would thank you very
much.

Regards

> jana.krajcovic...@shmu.sk

[Jana Krajcovicova]

Ricardo,

You need to have GRASS GIS software installed first, and to understand a little bit its basics. Then you need to create a location with global land cover projection settings. However, once you have GRASS installed, I can send you somehow (it is quite large) my GLC Europe location packed - it already contains imported and reclassed data.
There, you use GRASS native functions for setting a particular domain corners and resolution. Then you export it from GIS to ASCII.

The script I was talking about is taking xyz ASCII landuse and terrain and creates a geofile. It is written in perl - if you are familiar with it, and uses GMT(Generic Mapping Tools) library which you need to have installed (it is an open source soft, too).

If you operate under Linux you may have all those (Perl, GMT) preinstalled and my procedure may be convenient and rather straightforward for you, including the perl script. If you are using Windows, you can still use the GRASS GIS part of it, but the rest is on you.

Let me know if you are still interested.

Jana

Once you have

jana.kra...@shmu.sk

[Francesca Frabetti]

Dear Jana, your indication seems to be very useful.

There's the chance to upload files to our discussion page; you may try to upload a compressed archive; if you have problems with it, just send me a private message!

F.

[Ricardo T. Costa]

Dear Jana,

thanks for the support, in fact I'm aware of the software and
programming language you make reference, I've even studied them for a
moment and I guess sooner or later I'll need to get back to it, that's
why they'll remain installed on my system. Yesterday there were some
advances on script writing around here and there was a GEO.dat file
produced with success (I'm running some tests now), so maybe it won't
be necessary your material after all (although I thank you very much
anyway), but let's wait and see and if it turns out differently from
what's expected I'll report back.

Personally I find it really annoying, being at one step from running
all of the pre-processors successfully and knowing that the only
mistake is concentrated in just one single file format and maybe even
some few header records I would say. I almost could bet it was just a
matter of having the right information about the creation of the USGS
LULC CTG format, but ok... I'll postpone this for now and when I've
got free time (mentally included) I'll continue to work on that.

Thanks again and best regards

> jana.krajcovic...@shmu.sk

[Jana Krajcovicova]

OK, Francesca, I will "tidy up" the data and make a README file for them (with the reference to the original data and the procedure applied). I will have time for that next week.

J.

[Vecchiocattivi Marco]

I'm using CLC2000 too, but with another approach:

With Grass Gis, I've exported the area around the region where I work
into an ascii file and I've converted the coordinate system from CLC to
WGS84 (and changed all the 255 values into 44, that is from "missing" to
"sea/ocean"...).
Then, I'm using this file with a modified version of ctgproc program
that reads this ascii file and creates the usual LU.DAT file
(it's a very small change because ctgproc has already the possibility to
read a generic ascii file but in the format used in New Zealand and with
NZ land-use codes).

Then, whenever I need to create a new Calmet/Calpuff domain, I'm using
this file in the usual workflow we all know
(terrel+ctgproc+makegeo+etc.). Moreove, by going this way, I'm able to
retain all the calculations ctgproc and makegeo do with fractional
landuse values at smaller scale than the Calmet grid.

Maybe, if you are not using Linux or you don't have a fortran compiler
for windows, the only problem would be to recompile ctgproc...

If someone is interested, I can post detailed instructions on what I've
done with grass and the changes made to ctgproc.

Marco

[Jana Krajcovicova]

Hi Marco,

This  is of course a good idea as it retains the functionality of ctgproc. Could you please send me the modified ctgproc source code?

Thanks,

Jana

[stefano bagli]

Dear Marco,
that's a good idea.
Can you send me the details in order to modify the ctgproc lines.
Regards
Stefano

-----Messaggio originale-----
Da: european-calpuff-us...@googlegroups.com
[mailto:european-calpuff-us...@googlegroups.com] Per conto
di Vecchiocattivi Marco
Inviato: martedì 4 maggio 2010 16.23
A: european-calpuff-us...@googlegroups.com
Oggetto: R: Land Use Land Cover Data

Nessun virus nel messaggio in arrivo.
Controllato da AVG - www.avg.com
Versione: 9.0.814 / Database dei virus: 271.1.1/2851 - Data di rilascio:
05/04/10 20:27:00

[Nicola Mezzadri]

Dear Marco, I'm interested too in ctgproc modified lines.
Thank you in advance.

Nicola

-----Messaggio originale-----
Da: european-calpuff-us...@googlegroups.com [mailto:european-calpuff-us...@googlegroups.com] Per conto di Vecchiocattivi Marco
Inviato: martedì 4 maggio 2010 16.23
A: european-calpuff-us...@googlegroups.com
Oggetto: R: Land Use Land Cover Data

[Vecchiocattivi Marco]

At the end of this email, I've put the lines of ctgproc that I've
changed, but I'd like to comment a little what I've done.

I'm using a "personal" (and I don't know how accurate...) guess on the
conversion between CLC land-use codes and ctgproc ones (that's the
modified nzcat vector).

There's one thing that can be improved but, actually, I haven't figured
out how to do it and is how to insert irrigated lands (in the docs it
seems
(in diff format).

The format of the ascii file is a space (maybe even commas) separated
values for lon (real) + lat (real) + clc_code (integer) as the
following:

11.14200 43.96948 20
11.14325 43.96947 20
...

Where lat/lon are in WGS-84 datum.
You can obtain this file with these commands in grass (after you have
imported clc raster file and roughly defined the computational area
where you are interested, otherwise, for the entire CLC dataset, it
takes a very looong time...):

r.out.xyz input=clc output=clc_out.dat fs=" "
m.proj -o -d input=clc_out.dat output=clc_wgs84.dat
perl -ne '/^([.0-9]+)\s+([.0-9]+)\s+([0-9]+)\.0+$/;printf "$1 $2
%i\n",($3==255?44:$3);' clc_wgs84.dat > clc_landuse.dat

The last line is a perl script that do some cosmetics on the file and,
in case of "missing" values (255), it converts them to "sea/ocean" (44)
CLC code.

As usual, if you are recompiling all the source for a different
architecture/compiler, you should modify at least the last or few last
subroutines in calutils.for... (mine modifications are not included in
the diff output).

Here are the changes I made in ctgproc.for and params.ctg:

diff -ru v3.0.orig/ctgproc.for v3.0/ctgproc.for
--- v3.0.orig/ctgproc.for 2010-04-12 09:42:50.000000000 +0200
+++ v3.0/ctgproc.for 2010-05-04 15:37:11.000000000 +0200
@@ -480,14 +480,11 @@
data itab /16,21,21,21,21,21,31,32,33,33,
1 41,41,42,42,43,52,62,61,
2 77,82,81,85,83,91/
- data nzcat /55,8*0,16,
- 1 14,8*0,21,
- 2 22,8*0,43,
- 3 43,8*0,32,
- 4 2*0,61,6*0,52,
- 5 9*0,62,
- 6 62,8*0,75,
- 7 72,74/
+ data nzcat /11,11,15,14,14,14,75,17,16,17,
+ 1 17,21,21,21,22,22,22,21,24,24,
+ 2 24,24,41,42,43,31,32,32,32,72,
+ 3 74,77,77,91,62,61,62,62,62,51,
+ 4 52,54,54,55/
data nlcd92/10*0,
1 52,91,8*0,
2 11,11,13,7*0,
@@ -2164,13 +2161,15 @@
call CTRANS(kf,xdum,xdum,xdum,xdum,ltrans,caction,vecti,vecto)

c --- Read each record
-3 read(ioinp,*,end=999) nobs,nzlu,rnlat,relon
+3 read(ioinp,*,end=999) relon,rnlat,nzlu
nrec=nrec+1
nread=nread+1

c --- Convert the NZ landuse class,
-c --- catching '0' at edge of domain and resetting to '1'
- if(nzlu.eq.0) nzlu=1
+ if(nzlu.lt.1 .or. nzlu.gt.44) then
+ print *,'CLC land use category is out of range:',nzlu
+ stop
+ endif
lucat=nzcat(nzlu)

c --- Convert Lat/Lon to grid km
diff -ru v3.0.orig/params.ctg v3.0/params.ctg
--- v3.0.orig/params.ctg 2010-04-12 09:43:04.000000000 +0200
+++ v3.0/params.ctg 2010-05-04 12:21:11.000000000 +0200
@@ -13,7 +13,7 @@
parameter (iogshhs=31,iobln=32)
parameter (iosnow=33,iosng=34,iolug=35)
parameter (mc = 24)
- parameter (mzct=72)
+ parameter (mzct=44)
parameter (mnlcd = 99)
parameter (mxcoast=10000,mxcoastp=1000000)
parameter (mxfil=250)



(sorry for the long email)

Marco

[Valentina Stocca]

Hi to everybody,
I'm also dealing with the usage of CLC data with CALPUFF. Following
the very good and clear instructions posted by Marco, I was able to
obtain the file that he called clc_wgs84.dat. I opened it with an
editor and it seemed reasonable. Data were of the type:
13.74708075 45.68911964 2
13.74836146 45.68907434 2
13.74964218 45.68902901 2

After that I had two problems:
1) when I run the perl script I obtained a file clc_landuse.dat
containing only 0 values (this maybe is caused by my very low perl
knowledge)
I overwent this problem simply replacing with an editor the 255 values
with 44, but I'm not sure that the final form of the file I have is
the same of the Marco's one.

2) I was not able to compile ctgproc.for
I'm under Linux platform and I'm using the intel ifort compiler
version 10.1.008.
The warning and error messages were, respectively, of the type:
....
fortcom: Warning: snow.ctg, line 24: Because of COMMON, the alignment
of object is inconsistent with its type [IDATEEND]
& ,idatebeg,idateend,idate,istart
------------------^
fortcom: Error: ctgproc.for, line 4880: Not a valid value for the char-
expr in this connect-spec. ['transparent ']
open(unit=iogshhs,file=gshhsin,access=caccess,form=cform,
--------------------------------------------^
compilation aborted for ctgproc.for (code 1)

I know that some changes should be made in calutils.for and in
params.ctg but I worryed that I'm using the wrong ones since no
options were available for the ifort compiler.
Does anyone know how could I overcome this problems?
Thanks in advance for your help,
Valentina Stocca

Valentina Stocca, Ph.D.
Department of Civil and Environmental Engineering
University of Trieste,
P.le Europa 1, 34100 Trieste, Italy
Phone: +39-040-558-7803
mail: vales...@gmail.com

On 5 Mag, 12:15, "Vecchiocattivi Marco"

[Vecchiocattivi Marco]

Hi Valentina,

> 1) when I run the perl script I obtained a file clc_landuse.dat
> containing only 0 values (this maybe is caused by my very low perl
> knowledge)
> I overwent this problem simply replacing with an editor the 255 values
> with 44, but I'm not sure that the final form of the file I have is
> the same of the Marco's one.

Yes, it should be. The rationale behind the perl script is that it must
change the land use code data type from a real to an integer one (es.
12.0000000 -> 12) in order to let ctgproc read it without errors.
After that, it changes all missing/255 values to sea-ocean/44 ones,
again because in ctgproc this is used as the index of an array with 44
values to translate land-use codes.

These two operations are ok even if you do them in other ways (es. by
using a text editor).

Please note that in the mail I've sent, you've found a two line perl
command that should really be just one line! That line wrapping was done
by my mail client, not by me...

> 2) I was not able to compile ctgproc.for
> I'm under Linux platform and I'm using the intel ifort compiler
> version 10.1.008.
> The warning and error messages were, respectively, of the type:
> ....
> fortcom: Warning: snow.ctg, line 24: Because of COMMON, the alignment
> of object is inconsistent with its type [IDATEEND]
> & ,idatebeg,idateend,idate,istart
> ------------------^
> fortcom: Error: ctgproc.for, line 4880: Not a valid value for the
char-
> expr in this connect-spec. ['transparent ']
> open(unit=iogshhs,file=gshhsin,access=caccess,form=cform,
> --------------------------------------------^
> compilation aborted for ctgproc.for (code 1)

You can ignore the first warning... I've had that too and I think it's a
little bug in the snow cover handler part of the code...
The second issue that blocks you, that error happened even to me. It's a
lahey fortran compiler specific open option. This option should instruct
the open intrinsic function to handle a simple binary file (not a
fortran one).

In my case (with gfortran), I've resolved this issue by changing
"transparent" with "stream" in the params.ctg file...

> I know that some changes should be made in calutils.for and in
> params.ctg but I worryed that I'm using the wrong ones since no
> options were available for the ifort compiler.

Here is the complete differences list between the plain source files and
the one I've changed (with even calutils.for diffs). Please, note that
these changes do work with gfortran but I haven't tested them with other
compilers:

diff -ru v3.0.orig/calutils.for v3.0/calutils.for
--- v3.0.orig/calutils.for 2009-05-11 15:51:23.000000000 +0200
+++ v3.0/calutils.for 2010-04-12 09:42:02.000000000 +0200
@@ -2879,7 +2879,7 @@
c ------------------
c --- Lahey compiler
c ------------------
- call getcl(ctext)
+c call getcl(ctext)
c
c ----------------------
c --- COMPAQ DF compiler
diff -ru v3.0.orig/ctgproc.for v3.0/ctgproc.for
--- v3.0.orig/ctgproc.for 2009-06-08 21:01:53.000000000 +0200

+++ v3.0/ctgproc.for 2010-05-04 15:37:11.000000000 +0200
@@ -480,14 +480,11 @@
data itab /16,21,21,21,21,21,31,32,33,33,
1 41,41,42,42,43,52,62,61,
2 77,82,81,85,83,91/
- data nzcat /55,8*0,16,
- 1 14,8*0,21,
- 2 22,8*0,43,
- 3 43,8*0,32,
- 4 2*0,61,6*0,52,
- 5 9*0,62,
- 6 62,8*0,75,
- 7 72,74/
+ data nzcat /11,11,15,14,14,14,75,17,16,17,
+ 1 17,21,21,21,22,22,22,21,24,24,
+ 2 24,24,41,42,43,31,32,32,32,72,
+ 3 74,77,77,91,62,61,62,62,62,51,
+ 4 52,54,54,55/
data nlcd92/10*0,
1 52,91,8*0,
2 11,11,13,7*0,

@@ -1856,7 +1853,7 @@
c --- Open Input Data File
if(lulc(kf).eq.2.or.lulc(kf).eq.4) then
open(ioinp,file=luindat(kf), status='old',form=cform,
- 1 access=caccess, recl=irecl)
+ 1 access=caccess)
else
open(ioinp,file=luindat(kf), status='old')
endif

@@ -2164,13 +2161,15 @@
call CTRANS(kf,xdum,xdum,xdum,xdum,ltrans,caction,vecti,vecto)

c --- Read each record
-3 read(ioinp,*,end=999) nobs,nzlu,rnlat,relon
+3 read(ioinp,*,end=999) relon,rnlat,nzlu
nrec=nrec+1
nread=nread+1

c --- Convert the NZ landuse class,
-c --- catching '0' at edge of domain and resetting to '1'
- if(nzlu.eq.0) nzlu=1
+ if(nzlu.lt.1 .or. nzlu.gt.44) then

+ print *,'Original land use category is out of range:',nzlu

+ stop
+ endif
lucat=nzcat(nzlu)

c --- Convert Lat/Lon to grid km

@@ -4878,7 +4877,7 @@
c Open the GSHHS full-resolution file
c
open(unit=iogshhs,file=gshhsin,access=caccess,form=cform,
- & status='OLD',recl=irecl)
+ & status='OLD')
c
c Check if the current machine is BIG-ENDIAN
c
diff -ru v3.0.orig/params.ctg v3.0/params.ctg
--- v3.0.orig/params.ctg 2009-05-22 15:59:35.000000000 +0200

+++ v3.0/params.ctg 2010-05-04 12:21:11.000000000 +0200
@@ -13,7 +13,7 @@
parameter (iogshhs=31,iobln=32)
parameter (iosnow=33,iosng=34,iolug=35)
parameter (mc = 24)
- parameter (mzct=72)
+ parameter (mzct=44)
parameter (mnlcd = 99)
parameter (mxcoast=10000,mxcoastp=1000000)
parameter (mxfil=250)

@@ -27,7 +27,7 @@
c ----------------------
c --- Lahey F95 Compiler
c ----------------------
- parameter(cform='unformatted', caccess='transparent', irecl=1)
+ parameter(cform='unformatted', caccess='stream', irecl=1)
c ----------------------
c --- Compaq DF Compiler
c ----------------------

Ciao,
Marco

[Valentina Stocca]

Hi Marco!
Thanks a lot for your help,
Ciao
Valentina

On 3 Giu, 12:43, "Vecchiocattivi Marco"

[Silvia Maltagliati]

Dear all,
I've talked about our forum to some colleagues of mine from ARPA-Emilia
Romagna. They have
been working on CALMET-CALPUFF for years and gained good level results
in regional applications
(for example
http://www.arpa.emr.it/sim/?qualita_aria/altezza_rimescolamento shows
maps of the mixing height
computed with CALMET).
One of them, Enrico Minguzzi, and his graduate student Sara Zaniboni
would like to join the forum and the
discussion.
Are they welcome? (I'm positive)

Thank you for your attention

Silvia

--
Dott.SILVIA MALTAGLIATI, PhD in Ingegneria Energetica
Articolazione Funzionale Regionale - Modellistica Previsionale
ARPAT- Via Ponte alle Mosse 211
50144 FIRENZE
Tel 0553206028 Fax 0553206218

[stefano bagli]

I agree with Silvia.
Enrico and his team can bring high contribute to our user group.
Ciao
Stefano Bagli

-----Messaggio originale-----
Da: european-calpuff-us...@googlegroups.com
[mailto:european-calpuff-us...@googlegroups.com] Per conto

di Silvia Maltagliati
Inviato: lunedì 21 giugno 2010 19.13
A: european-calpuff-us...@googlegroups.com
Oggetto: joining the forum

Silvia

Nessun virus nel messaggio in arrivo.
Controllato da AVG - www.avg.com

Versione: 9.0.829 / Database dei virus: 271.1.1/2927 - Data di rilascio:
06/21/10 08:36:00

[Nicola Mezzadri]

They are of course warmly welcome!
Nicola

-----Messaggio originale-----
Da: european-calpuff-us...@googlegroups.com [mailto:european-calpuff-us...@googlegroups.com] Per conto di Silvia Maltagliati

Inviato: Monday, June 21, 2010 7:13 PM

A: european-calpuff-us...@googlegroups.com
Oggetto: joining the forum

Dear all,

[Francesca Frabetti]

Hi, in order to add them to the group I just need their e-mail address.

Bye

2010/6/21 Silvia Maltagliati <s.malt...@arpat.toscana.it>

[Silvia Maltagliati]

Francesca Frabetti ha scritto:

here they are: szan...@arpa.emr.it emin...@arpa.emr.it
thanks a lot!

[Silvia Maltagliati]

Dear all,

I have a basic question about time coherence between simulation and
observation data:
do the surface data at a time correspond to the previous or to the next
hour?

for example: wind at 21 means meand wind measured during 20-21 or 21-22?
(the same for upper data?)

thanks!

Silvia

[Francesca]

Dear all.
I've got a question about timing too.
It's about Italy, but I guess tha many of you had to deal with the
same question

Italian time is UTC+1/GMT+01 (east greenwich we are all in positive
time zones)
calmet user guide contains examples of surface data using USA hours,
so the time zones are 05 06 07 08, given as positive numbers, even if
they are negative when expressed as GMT. this is the reason why
running calmet with italian coords it does request us to use time zone
-01.

If I'm not wrong, it means that surface data (given in local time)
must have a "false GMT time zone" as it were -1 (I'm not sure I
explained it well) in order to compensate positive american GMT time
zones.

what about upper air data?

thanks
F.F.

Silvia I answered you with a private message!



On 1 Set, 13:28, Silvia Maltagliati <s.maltagli...@arpat.toscana.it>
wrote:

[Nicola Mezzadri]

Dear Francesca,

you can read the email Joe Scire sent me about this topic, and I think it's quite clear and useful.
Hope it's helpful for you too.

Nicola

------------------------
Da: Scire, Joseph (Lowell,MA-US) [mailto:JSc...@TRCSOLUTIONS.com]
Inviato: Thursday, May 06, 2010 3:00 AM
A: Nicola Mezzadri
Oggetto: RE: tIME ZONE

Nicola,

There are two ways time zones are used in the CALPUFF system programs. The new way used in most programs is as an explicit text string such as "UTC+0100" which would be for Italy. This method is clear and unambiguous.

The second way time zones are entered (the old way, but it is still how some programs work) is to treat the time zone as an integer number. When the time zone is an integer, the convention used is western hemisphere used a positive value and the eastern hemisphere uses negative value, so the time zone for Italy in the integer format would be -1.

To summarize:

Time Zone (new format) Time Zone (old integer format)

UTC+0100 -1 (Italy)
UTC+0200 -2
UTC+0300 -3

UTC+0000 0 (GMT)
UTC-0500 5 (Eastern Standard Time USA, e.g., Boston)
UTC-0600 6 (Central Standard Time USA, e.g., Chicago)

I hope this is clear.

Joe
------------------------------------------
Joseph S. Scire, CCM
TRC
Vice President, Atmospheric Studies Group,
650 Suffolk Street,
Lowell, Massachusetts 01854
USA

tel: (978) 656-3627
mobile: (978) 697-0830
fax: (978) 453-1995

email: jsc...@trcsolutions.com
or jsc...@alum.mit.edu

-----Messaggio originale-----
Da: european-calpuff-us...@googlegroups.com [mailto:european-calpuff-us...@googlegroups.com] Per conto di Francesca
Inviato: Wednesday, September 15, 2010 3:23 PM
A: european-calpuff-user-discussion-group
Oggetto: Re: timing in suface data files

[Silvia Maltagliati]

Nicola Mezzadri ha scritto:

Fine, that's the way it works.
Thanks

[Pier Luigi Benedetti]

HI,

i need to import in calpuff corine raster file. Can you send me the GLC Europe location packed?

Thanks in advance.

Pier Luigi Benedetti

[Riccardo Giannone M.Sc. Chemical Engineering]

Dear members

I am Riccardo Giannone, a chemical engineer, and I am learning calpuff (CALPro on Windows xp) in order to use it for my job in an Environmental Engineering Company.  

I am in trouble with ctgproc, in particular with the Corine 2006 data. I have found that the Data need to be converted in USGS format with a GIS software (I am using GRASS GIS) but it needs a file with reclassification rules.

Where can i find this file?

Regards

Riccardo 

[Nicola Mezzadri]

Dear Riccardo,

I think you have to establish yourself a riclassification rule knowing A) CLC classes B) USGS land use classes (Table 8.6 and 8.7 on pages 8.58 and 8.59 in CALPUFF Modeling System Version 6 User Instructions (April 2011))

Regards

 

Nicola

 

Da: 'Riccardo Giannone M.Sc. Chemical Engineering' via european-calpuff-user-discussion-group [mailto:european-calpuff-us...@googlegroups.com]
Inviato: Monday, July 18, 2016 12:05 PM
A: european-calpuff-user-discussion-group
Cc: stefan...@gecosistema.eu; ricardota...@gmail.com
Oggetto: Re: Land Use Land Cover Data

--
You received this message because you are subscribed to the Google Groups "european-calpuff-user-discussion-group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to european-calpuff-user-dis...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Riccardo Giannone M.Sc. Chemical Engineering]

Thank you Nicola,

I thought there were general rules of reclassification. 

Regards

Riccardo

Il giorno martedì 19 luglio 2016 14:01:40 UTC+2, Nicola Mezzadri ha scritto:

Dear Riccardo,

I think you have to establish yourself a riclassification rule knowing A) CLC classes B) USGS land use classes (Table 8.6 and 8.7 on pages 8.58 and 8.59 in CALPUFF Modeling System Version 6 User Instructions (April 2011))

Regards

 

Nicola

 

Da: 'Riccardo Giannone M.Sc. Chemical Engineering' via european-calpuff-user-discussion-group [mailto:european-calpuff-user-discussion-group@googlegroups.com]

Inviato: Monday, July 18, 2016 12:05 PM
A: european-calpuff-user-discussion-group
Cc: stefan...@gecosistema.eu; ricardota...@gmail.com
Oggetto: Re: Land Use Land Cover Data

 

 

Dear members

I am Riccardo Giannone, a chemical engineer, and I am learning calpuff (CALPro on Windows xp) in order to use it for my job in an Environmental Engineering Company.  

I am in trouble with ctgproc, in particular with the Corine 2006 data. I have found that the Data need to be converted in USGS format with a GIS software (I am using GRASS GIS) but it needs a file with reclassification rules.

Where can i find this file?

 

Regards

 

Riccardo 

--
You received this message because you are subscribed to the Google Groups "european-calpuff-user-discussion-group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to european-calpuff-user-discussion-group+unsubscribe@googlegroups.com.

[nicola....@gmail.com]

Hi all!

I'm tried to follow Marco's instructions by changing the .for file but I'm stuck in compiling it. Coud you please send me the built file or the .for file so I can see what is not working for me?

 

Best Regards

Nicola