stars-py-users — Help and support for STARS users

[STARS] The client can obtain the ball's current position, size, and color to permit display of the ball's moving image.

[Natacha h. <Nat...@ou...>]

H*E,R'E WE GO AGAI*N! 

T H-E B_I*G O,N E BEF+ORE T-H.E SEPTEMB'ER.RALL-Y! 
T-H+E MAR KET IS AB OUT TO P.O*P,, A,N.D SO IS E+X-M T,! 


Tick.: E*X,M-T 
5-d+ay po,tentia+l: 0-..4 0 
Fir+m: E'X+CHANGE MO BILE T*E+L'E (Ot,her O T'C*: E-XMT.PK) 


A*s,k.: 0,. 1.0 (+2,5.,00%) UP TO 2.5'% in 1 day


N,o+t o_n,l_y d+o e*s t+h i s f'i r+m h'a v*e gre*at funda menta+ls, 

b_u*t getti,ng t'h-i-s op_portuni ty at t+h e rig_ht t,i,m*e', 

r_ight be,fore t,h+e rall y is w*h+a-t ma_kes t.h'i s d-e_a-l so swe'et! 
T_h,i,s a g*reat op.portun+ity to at leas-t dou_ble up!



It co*uld be lea_rned. 
Es w_a*r jet_zt n_u_r n,o'c'h d-i,e Frage+, in w.elchem exakt+en Verh-ul-tnis zu+eina.nder m+a.n s.i'e fuge*n musste,. 

At l*east t+h.e c,o*mputer pr intout,s s-h o-w th_at, w h'e_n t-here a+r.e s-i x or m'o,r_e ba*nds th,ere, t'h.e shi'ps d+on't c_o,m e b_a c-k-. 

Geor,ge Had_ley look.ed in at t.h,e ch.anged sc,ene. 

Y.o.u c-a+n a,l s,o ac'hieve t_h+e s,a_m,e th,ing by cli_c_king t+h e DL*LSKEL. 

[STARS] We don't have any answers to the why questions.

[qw G. <qw...@su...>]

H*E R,E WE GO AGAIN ! 

T-H E B_I.G O.N.E BEF-ORE T_H_E SEPTEMBER.RALL,Y.! 

T,H+E MARK-ET IS A BOUT TO P-O*P , A+N D SO IS E'X-M*T-! 


Ti'ck: E-X M_T 
5--day pote-nti+al: 0+..4-0 

F_irm: EXCHAN* GE M.OBILE T_E L.E ( Other O+T.C,: EXMT,.PK) 
A-s.k': 0 ._1,0 (+*25'.00%) UP TO 2_5,% in 1 day


N-o,t o+n_l'y d*o+e.s t,h'i.s f'i,r.m h a*v.e grea't fundam.ent_als, 
b'u*t g_etting t-h i s opportu+*nity at t_h'e righ*t t i-m*e*, 

ri'ght b'efore t*h'e rall y is w h,a_t m-akes t.h i s d,e+a_l so s weet! 
T.h,i.s a gre at oppor tu.nity to at leas t d-ouble up!




A_l_l I c+a n s'a_y is t'h'a t i't.'-s a g_o.o_d th ing I st'opped by w'h-e.n I d-i d*, ra ther t h'a.n f,i,v_e or t-e n m+inutes lat,er. 

Scroll,D-C Scro.lls a rect.ang*le of b i,t_s horizonta*ll+y a.n_d verti*ca lly. 
B*u t w_h-a,t d o_e's t.h,a+t m'ean, a_nyway, he add.ed bitte,*rly. 

I h_a.v.e a+l-s+o b.e,e-n ask+ed a l.o't a'bout w,h-a t t'h'i,s "b*ug" affects . 

RAS_DLG c'a.n be c*alled f.r'o'm m_'ultiple thre_ads in a proc.ess so t-h e u+s*e of g_lobal st,ate inf+orma+tion, l.i_k e 'P,bdat a' is e*li+minated in fav+or of ret urne*d co-ntext block*s. 

[STARS] We are working on it, and it should be ready anytime now.

[hongdao K. <Kom...@gl...>]

T+H,E B_I+G O_N.E BEF'ORE T.H+E S*EPTEMBER,.RALLY! 

H.E,R-E WE GO AGAIN.! 
T H-E MARKE T IS ABOU_T TO P-O*P', A'N,D SO IS E.X.M+T+! 


T_ick: E+X_M,T 
F,irm: EXCHAN-G E M.OBILE T_E-L-E (*Other O T'C.: EXMT.-PK) 

5_-day potentia+l.: 0'._4 0 
A.s.k+: 0 .'1.0 ( +*25.00%) (_U,P TO 2+5'% in 1 d*a_y-) 


N+o't o n,l*y d.o+e.s t.h+i,s f,i_r+m h*a'v*e g*reat fu-ndam,entals, 

b,u+t gett+ing t h_i+s opp-ortunit*y at t.h_e righ,t ti.me, righ.t =
bef-ore t_h.e rall,y is w.h*a*t make-s t-h_i.s d_e_a l so sweet.! 

T_h+i.s a gre.at opp-ort-unity to at le ast doubl-e up!


We ll, at t h*e leas-t, he cou ld be ar ound to g-e_t t_h*e,m a.w.a_y =
w,h+e_n it a+l*l f,e*l+l apart . 
Tu n*' y as jamai_s m+i-s l-e,s pied s, et tu en parles*. 

Worr*ied t*h-a+t he w a.s someh*ow re achi.ng insid'e h-e_r ches-t a*n.d =
m+aking h'e'r h.eart t'u'r-n o*v e*r a_n*d h+e_r who'le b,o d*y qu+iver. =

Allow,s a par'.ticular memb-er of an i,ns-trumented clas's to be =
i'gnored by man agem*ent i-nst,rumentation P+rovide.s h_elper functio- =
ns f*o+r expos_*ing even_ts a+n+d d.a't_a f*o-r mana+g ement. 
It w a s t'h'e sk ,eleton in h_i_s h'ouse, a*n'd a+l.l t+h+e famil_y =
wa+lked by it in t*error a.n d si'lence. 

[STARS] MANUALLY skinning the mutant - crUsAdEr.

[Veeranna K. <Kra...@fr...>]

T,H_E B+I,G O*N_E BEFO,RE T*H'E SEP-TEMBER-.RALLY! 
H,E-R+E WE GO AGAI-N! 
T H*E MARKE,T IS AB-OUT TO P,O-P_, A*N-D SO IS E'X*M.T-! 


T-ick: E'X_M+T 

Fir'm: E'XCH*ANGE MOBIL*E T*E-L'E (Othe'r O,T.C : EX'MT.PK) 
5-da'y pot entia-l: 0-._4_0 
A's_k.: 0,.*1'0 (+ 25_.00%) (.U*P TO 2,5'% in 1 d a,y.) 


N-o't o*n+l*y d*o_e*s t'h+i s f.i,r m h+a+v*e grea*t fu*ndamental_s, 
b.u+t ge_tting t'h i s opportuni't-y at t.h e r*ight t+ime, r ight befo.re t h-e ral ly is w-h+a,t ma'kes t h-i_s d*e+a,l so sweet*! 

T+h i,s a g_reat oppo__rtunity to at l east d_ouble up!




U*s+e t+h'e Chang.e Di.rec tory c+ommand to chan*ge to t_h*e Sec+urity.2 di,rector'y. 

If I knocke*d on t'h+e co.ver of o_u_r d.u-c t t*h.e'y c.ould h*e a+r me.
D.i,r'e Strai_ts - B,e.s t - Track*02. 

Ret'urn Va_lue T h*e re.turn valu e s-pecif*ies t+h*e x- a'n'd y-extent''s ( i.n l-ogical units+). 
He m*a_d.e a tea-rful farewe.*ll to h,i's Order*, s*tepped i+n-t+o h*i+s t+i_m.e bu*bble, wh'ich p_romp*tly disap_pea red i+n.t-o t'i m*e'. 

[STARS] His face and in particular his dress seemed strangely familiar.

[myriam D. <Dur...@TS...>]

H E R*E WE GO AGAI-N! 

T'H E B*I,G O-N-E B*EFORE T.H.E SEPTEMBER.+RAL-LY! 
T*H*E M+ARKET IS ABOU T TO P O+P,, A N-D SO IS E+X'M+T,! 



Fi_rm: EX*CHAN'GE MO,BILE T_E,L,E (-Other O+T*C_: EXM T.PK) 

Tic'k: E.X+M+T 
A.s k-: 0..'0_8 
5-da y potential_.: 0 .'4_0 



T h+i.s a grea+t opportu-n-ity to at lea+st d-ouble up!

N-o_t o'n*l*y d-o'e,s t*h i's f,i,r'm h,a v-e grea_t fu ndament als, b'u+t gett+ing t h+i's opportun-it-y at t h*e r-ight t.ime, ri*ght b-efore t,h e ra*lly is w+h-a't ma_kes t-h+i+s d-e.a*l so swee.t! 



W atch it s.o,a*r.! 


T'h e Rem,ove meth_od take+s t.h*e n_a_m*e of a coun* ter, remo_ves t*h+e counte,r f'r.o*m t'h'e C o unters objec-t, a,n*d del etes t_h+e c+ounter f*r-o,m t+h e Cou nter*s. 

Y+o u c*a.n lis.ten to y*o+u,r messa-ge-s th-rough a tel*ephon-e han+dset -- j,u s-t connec_t t,h.e t elephon e to t h_e mo_dem a-n d sele ct Hand set f-o+r y+o_u,r out_put. 

E.very shop+own+er w.a's on t-h,e s.i,d e of t.h*e Thr ee F a_t M+e n*, be cause he h_imself w_a's f_a*t a.n,d r-i-c,h'. 

T'h*e R'epeat m_e'n'u i't.e-m ch+anges to Ca*n't Repea_t if y_o+u c annot repe+at y,o*u_r l'a,s't action_. 
I c+an't stan-d ano'ther t_w-o mont_hs w i.t,h o-n l.y Dudle.y to t.a l_k to.

[STARS] This is vital in routing information across the Internet.

[lasisi n. <nat...@ar...>]

T.h-i-s g e_m is rea,lly movabl*e*!! 
T.h-i's o-n*e is re.ally profitabl._e!!! 

H-a*v'e y'o-u b'e-e*n watc-hin g t-h,i+s f-o r t'h'e l,a s*t w'e.e+k'? 



T_a,k-e a l*o.o'k at it:
rec ent n'e,w+s rele+as es s-e*n.t gen erat.ing g rowing i_nter+est in C_Y_T V 


Co,mpan*y: CHI+NA YO UTV C_O*R.P (*O,T-C BB:CYTV-,.OB) 
S t o c k:      C.Y T,V 
Curren*t P_rice: $..*4*9 
4 t'h S__traight d+a y's we h'a'v+e s e+e_n t.h+i_s c,limb. (-S.e_e Y*ahoo Cha*r-t-New N'e,w+s relea'se) 








T+h*i s o+n*e h+a+s h*a+d n.i,c'e retur ns f+o'r investo,r.s o*v e,r t*h,e su_mmer, and

n+o-w sho ws promi,se to beg,in a se*cond w+a,v_e of ret+urns. 


K*e.e'p a e*y.e o'u't agai'n on Wedne,*sday A'u-g 15... . 



NO,TS+RCCOPY Copi.es t h.e i'nver ted sou.rce bit,map to t_h e des'tin.ation. 

N o w-, I h a_v,e no talen-t f.o*r aski'ng questio*n.s l'i*k.e t+h+a.t-. 

O, that',s t+h+e sty*le. 

Thes.e f'ellows w+h.o h.a.v-e buil-t up larg e commer'cia,l empir+es a'r_e a'lways w'h+a't I h*a-v*e h_eard Jeev+es c,a.l-l orotund-. 

F-3-5 du,ring t+h e cre'atio-n of a CD.

[STARS] investor_tip-192166423

[cen <ce...@pu...>]

[STARS] market_watch-9724844421

[rita <Ol...@pu...>]

[STARS] urgent_notific-24669598

[Hwee <Mac...@ca...>]

[STARS] Can't open the project I created in 0.8.2

[Mikko M. <mik...@sa...>]

Hi

I am a PhD student and I am quite new to STARS. I have read the tutorial
and managed to create and analyse the California tutorial project with
Projectmaker without any problems. I then created my own project with my
own data, but problems arrived when I tried to open it in STARS. The
program just desperately tries to read project file and I get the
message in starsgui.exe.log:

=20

Exception in Tkinter callback

Traceback (most recent call last):

  File "Tkinter.pyc", line 1345, in __call__

  File "starsgui.py", line 1729, in openProject

  File "stars.pyc", line 198, in ReadProjectFile

  File "stars.pyc", line 386, in ReadData

  File "Data.pyc", line 398, in __init__

IndexError: list index out of range

=20

Could someone please translate to me what is happening here? My project
is the only *.prj file in the directory, if that helps.

=20

Yours,

Mikko Moilanen

Re: [STARS] linux stars -- project maker

[Sergio R. <sj...@ma...>]

On Sep 26, 2005, at 10:25 AM, Alfred Nucci wrote:

> Guys,
>
>   I am working with the folks at the Center for Economic Studies (I  
> am on the research staff there) on spatial packages, including  
> STARS.  We have, for the most part, LINUX servers running .0.7.2a  
> (from 2004/07/12) version of STARS.  The STARS software itself can  
> be run but the Project Maker.py software does not function  
> completely ( You guys sent me a windows/xp beta version of STARS   
> when I encountered problems with project maker ).  For the (SuSe)  
> linux servsion, I get the error nessage:
>
> exception in  Tkinter callback last);
> ...
> File "ProjectMaker.py",  line 1369, in createIDAndNames
> name=uniqueNames[c]
> InderError: list index out of range
> {}
>
> Uh, help!
>

hi al,

we are close to finishing the next release of stars and will have  
fresh source code for the linux side shortly (in addition to a large  
number of new analytical methods, bug fixes, and documentation).

i'm hoping to get this done in the next two weeks or so.

--
Sergio J. Rey, Ph.D.
Professor of Geography
San Diego State University
San Diego, CA 92182
http://geography.sdsu.edu/People/Faculty/rey.html

[STARS] linux stars -- project maker

[Alfred N. <Alf...@ce...>]

Guys,

   I am working with the folks at the Center for Economic Studies (I am 
on the research staff there) on spatial packages, including STARS.  We 
have, for the most part, LINUX servers running .0.7.2a (from 2004/07/12) 
version of STARS.  The STARS software itself can be run but the Project 
Maker.py software does not function completely ( You guys sent me a 
windows/xp beta version of STARS  when I encountered problems with 
project maker ).  For the (SuSe) linux servsion, I get the error nessage:

exception in  Tkinter callback last);
 ...
 File "ProjectMaker.py",  line 1369, in createIDAndNames
 name=uniqueNames[c]
InderError: list index out of range
{}

Uh, help!

Thanks,
Al

[STARS] contiguity shape files etc.

[Alfred N. <Alf...@ce...>]

Julia/.Dave,

      Thanks for the postings.  The information has helped resolve 
several puzzles I confronted when I began using Geoda last Spring. 

      Two comments about my postings on topic of esri shapefiles.  One 
is my comment about arcview 3.3 relies upon my initial experience with 
geoda last Spring -- when I still had access to arcview 3.3. As Summer 
began, I installed arcgis 8.2/9.1 and uninstalled arcview from my pc. 
However, until late in Summer I was using shapefiles created in arcview 
-- importing them into arcgis without using any of the tools available 
(e.g.  clean and verify topology tools similar to arcinfo tools let  
alone creating personal geodatabase). in addition to using these 
shapefiles in geoda. This experience has led me not to use shapefiles 
from any source without verifying the integrity of their implied 
topology -- using either arcinfo or arcgis tools to conduct this 
verification.

       A second comment is about my experience with creating personal 
geodatabase in arcgis. It is important to invoke the topology 
clean/verify operations when creating this database before exporting a 
file (s) as shapefile. I have noticed that this resolves most issues 
associated with dissolve/join operations when creating contiguity files 
(see ps for my recent experience with STARS package).

      Dave, I received an email from a Katharine White about use of 
county shapefile.  I am not sure this is wise as this county file has 
several  features unique to the time period of my work -- 1900-2004 -- 
and my notions about independent cities -- I do not like them when 
treated as county-equivalents.  Let me know --  Paul, weigh in if 
appropriate. (Julia, I apologize for using this posting to discuss this.)

Al

ps.  I began using STARS (Space Time Analysis of Regional Systems) 
package several weeks ago.  I am currently using a beta version of this 
package to resolve  technical issues surrounding folders, newer 
features, etc. STARS creates rook/queen contiguity files -- just as 
geoda does.  However, my current experience is that geoda and STARS 
treat the issue of "legitimate" islands (e.g. Hawaiian islands) 
differently -- the contiguity file from STARS shows no islands while 
that of geoda does (e.g. for Hawaiian islands). I do not know what 
occurs when shapefiles have polygon slivers. Oh well ...

From: Julia Koschinsky <kos...@ui...>
Date: Thu Sep 08 14:03:23 CDT 2005
To: David Long <dl...@ss...>, ope...@sa...
Subject: Re: [Openspace] More on problems with Contiguity	Weights from Dissolved	Shapefiles...
k
Dave,

See the related thread in the Openspace archives on "No 
connectivty in data set" at 
http://sal.uiuc.edu/pipermail/openspace/2003-November/

The discussion focuses on digitizing errors that result in 
slivers and false zero neighbors but it is relevant to the 
dissolve issue as well. We've also frequently encountered 
the same problem with the dissolve operation you're 
describing. We usually use ArcInfo's CLEAN command to fix 
the file, which might be a solution if the 4mm turn out to 
be an issue (let me know if you want me to send you the 
cleaned file).

Julia

[STARS] stars geoda sas -- creating contiguity files

[alfred n. <an...@ce...>]

Guys,

   Thanks for getting back to me.  I am including the following information on moran s i calculated by geoda, stars (beta), and by a sas program I put together. The four variables are (annualized) county population growth for the 3065 us counties with boundaries standardized to account for county boundary changes between 1960-2000 and independent city thing. I apologize if this is becoming confusing.  What I have now discovered is that the beta stars creates queen contiguity files different from those of geoda (particularly in treatment of islands) and this is likely to be the source of much of the discrepancy showed below. 

  Hence,I was too hasty in my email below where I surmised that stars truncated moran's i values when displaying three signification digits to right of decimal vs four for geoda (and seven for sas code). This is only the case for the 1960-70 population measures.  Further, STARS moran's i measure is similar to that from sas code for 1990-00 population growth but geoda and SAS measures are more similar for 1970-80 and 1980-90 measures than those of STARS. I have been discussing this with folks from geoda but have yet to come to any resolution.


                                       GEODA                         STARS                   my SAS code

1960-70 population growth              .4686                         .468                    .4698343 
1970-80 population growth              .4906                         .497                    .4918964
1980-90 population growth              .5688                         .573                    .5702765
1990-00 population growth              .5223                         .524                    .5236971



Note the following:
1.  the weight matrix is a queen one (the geoda weight file is used in my sas code)
2.  STARS and GEODA appear to construct different contiguity (queen) files from the same data source (cleaned arcview shape file) -- at least in their treatment of islands. Note HI and AK are included in these data

    GEODA --  HI's four counties treated as islands in geoda queen weight file and four other counties treated as islands (this is default and I have not changed it); 
    STARS  -- STARS appears to be inconsistent on this, depending upon use of the beta or production version: the version of the weight file constructed with beta STARS has no islands, even for HI counties. However, the queen file I managed to create from the current production version of STARS appears to create a queen file with islands for HI.  (It would be nice to have fips codes rather than line numbers for the STARS datafile -- or is this another option I am not familiar with in STARS.) The beta version of STARS cannot use this latter version -- I get the infamous tinkter error when trying to invoke ESDA and moran's i.  

    I will continue to compare the geoda and stars contiguity file, looking for further discrepancies. I will also include the stars contiguity file in my sas code as a further check. If you can suggest further avenues for exploration, pass my way.

Al Nucci


On Fri, Sep 02, 2005 at 09:46:11AM -0400, alfred nucci wrote:

>> Guys,
>>=20
>>   Thanks for sending me beta (or almost) version of stars.  As I said=20
>> in previous posting, the project maker is much improved.  However, I=20
>> discovered three idiocyncracies with this software:
>  
>

thanks for taking the time to provide feedback - it is very helpful.

>>=20
>> 1.  The destination location of  rook/queen weight  (*.gal) files=20
>> appears to be the source for the csv/arcview project and hence it is not=
>  
>
=20

>> saved with the stars project if this in a different location.  Since I=20
>> believe in a previous posting you suggested that I keep arcview projects=
>  
>
=20

>> and stars projects in different folders so stars does not confuse the=20
>> two (Is this still the case?), this may may cause initial confusion when=
>  
>
=20

>> reading in the stars  project through main stars software -- apparently=
>  
>
=20

>> the project maker software keeps track of the location of the gal files.
>  
>


we will look into this. one short run solution is to name the stars
project differently than the arcview project. that way you should be
able to keep things in the same folder/directory.


>> 2.  When using the gal weight files to calculate moran's I, I noticed=20
>> that the value of this measure produced by stars is identical to that=20
>> produced by geoda, except geoda produces a measure with four digits to=20
>> right of decimal point while stars produces one with three.  In the even=
>  
>
=20

>> this fourth digit is 5 or greater, Stars does not round the third=20
>> digit.  Picky, I concede, but I have been comparing Moran's i values=20
>> calculated in different software and they are (inevitably?) different in=
>  
>
=20

>> the third or fourth position.
>  
>

stars does the calculation in full precision but for display of the
results things get truncated to 3 digits. we will probably make this an
option that the user can override (formatting that is).

just so i'm clear of what you mean, can you send me an example of a
value from stars and one from geoda that you are referring to? we work
closely with luc and his team so our results should be the same.



>> 3.  The  projectmaker software expects input as .csv file or arcview=20
>> project.  I noticed that this software defaults to a .dbf file when=20
>> there is an arcview shape file, but no arcview project file -- most=20
>> likely, an increasingly common occurrence for those of who have switched=
>  
>
=20

>> to arcgis. Is this important?
>  
>

basically we are assuming the availability of the .shp file and the .dbf
file as there are a lot of sites that distribute these without a project
file. so we went with that as our lowest common denominator. if you have
ideas/suggestions for dealing with the project files we would definitely
be interested in them.


again, thanks for the specific comments - not "picky" at all but the
kind of feedback that is very much appreciated.

s.

--=20
Serge Rey	http://geography.sdsu.edu/People/Faculty/rey.html
No falsehood is so fatal as that which is made an article of faith.
-- Thomas Paine

--ZwgA9U+XZDXt4+m+
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)

iD8DBQFDGGjlkUwz5faQld8RAvCbAJ0byKf7q+0TIqZA6U8FiEpdBvwErgCgkfgr
1pi6AJCBaPqFaHx4p+0MOTc=
=w8NI
-----END PGP SIGNATURE-----

--ZwgA9U+XZDXt4+m+--



--__--__--

_______________________________________________
Stars-py-users mailing list
Sta...@li...
https://lists.sourceforge.net/lists/listinfo/stars-py-users


End of Stars-py-users Digest

Re: [STARS] three comments about "beta" stars

[Serge R. <se...@ro...>]

On Fri, Sep 02, 2005 at 09:46:11AM -0400, alfred nucci wrote:
> Guys,
>=20
>   Thanks for sending me beta (or almost) version of stars.  As I said=20
> in previous posting, the project maker is much improved.  However, I=20
> discovered three idiocyncracies with this software:

thanks for taking the time to provide feedback - it is very helpful.
>=20
> 1.  The destination location of  rook/queen weight  (*.gal) files=20
> appears to be the source for the csv/arcview project and hence it is not=
=20
> saved with the stars project if this in a different location.  Since I=20
> believe in a previous posting you suggested that I keep arcview projects=
=20
> and stars projects in different folders so stars does not confuse the=20
> two (Is this still the case?), this may may cause initial confusion when=
=20
> reading in the stars  project through main stars software -- apparently=
=20
> the project maker software keeps track of the location of the gal files.


we will look into this. one short run solution is to name the stars
project differently than the arcview project. that way you should be
able to keep things in the same folder/directory.

> 2.  When using the gal weight files to calculate moran's I, I noticed=20
> that the value of this measure produced by stars is identical to that=20
> produced by geoda, except geoda produces a measure with four digits to=20
> right of decimal point while stars produces one with three.  In the even=
=20
> this fourth digit is 5 or greater, Stars does not round the third=20
> digit.  Picky, I concede, but I have been comparing Moran's i values=20
> calculated in different software and they are (inevitably?) different in=
=20
> the third or fourth position.

stars does the calculation in full precision but for display of the
results things get truncated to 3 digits. we will probably make this an
option that the user can override (formatting that is).

just so i'm clear of what you mean, can you send me an example of a
value from stars and one from geoda that you are referring to? we work
closely with luc and his team so our results should be the same.


> 3.  The  projectmaker software expects input as .csv file or arcview=20
> project.  I noticed that this software defaults to a .dbf file when=20
> there is an arcview shape file, but no arcview project file -- most=20
> likely, an increasingly common occurrence for those of who have switched=
=20
> to arcgis. Is this important?

basically we are assuming the availability of the .shp file and the .dbf
file as there are a lot of sites that distribute these without a project
file. so we went with that as our lowest common denominator. if you have
ideas/suggestions for dealing with the project files we would definitely
be interested in them.


again, thanks for the specific comments - not "picky" at all but the
kind of feedback that is very much appreciated.

s.

--=20
Serge Rey	http://geography.sdsu.edu/People/Faculty/rey.html
No falsehood is so fatal as that which is made an article of faith.
-- Thomas Paine

[STARS] three comments about "beta" stars

[alfred n. <an...@ce...>]

Guys,

   Thanks for sending me beta (or almost) version of stars.  As I said 
in previous posting, the project maker is much improved.  However, I 
discovered three idiocyncracies with this software:

1.  The destination location of  rook/queen weight  (*.gal) files 
appears to be the source for the csv/arcview project and hence it is not 
saved with the stars project if this in a different location.  Since I 
believe in a previous posting you suggested that I keep arcview projects 
and stars projects in different folders so stars does not confuse the 
two (Is this still the case?), this may may cause initial confusion when 
reading in the stars  project through main stars software -- apparently 
the project maker software keeps track of the location of the gal files.
2.  When using the gal weight files to calculate moran's I, I noticed 
that the value of this measure produced by stars is identical to that 
produced by geoda, except geoda produces a measure with four digits to 
right of decimal point while stars produces one with three.  In the even 
this fourth digit is 5 or greater, Stars does not round the third 
digit.  Picky, I concede, but I have been comparing Moran's i values 
calculated in different software and they are (inevitably?) different in 
the third or fourth position.
3.  The  projectmaker software expects input as .csv file or arcview 
project.  I noticed that this software defaults to a .dbf file when 
there is an arcview shape file, but no arcview project file -- most 
likely, an increasingly common occurrence for those of who have switched 
to arcgis. Is this important?

Thanks,
Al Nucci

Re: [STARS] thanks for beta stars -- now onto geography questions

[Mark J. <ja...@ma...>]

Hi Al,

You have a couple options for dealing with islands in STARS:

1) select queen contiguity when you are making the initial project in  
ProjectMaker and then edit the *.gal file by hand.   I.e. you could  
add neighbors to the appropriate "island" counties based on your own  
discretion.  This option isnt too much trouble if you only have to  
hand code a couple of instances.  (you can open up the project in  
STARS and middle click polygons to identify them.... this is probably  
the best way to match up who the island neighbors are)

2) you could create a distance-based weights matrix in the STARS  
environment (Data-->Matrix-->Create-->Distance-based)..... but there  
is not a sparse routine for this so if your project includes all of  
the US counties then I wouldnt suggest it.

* Perhaps in the next version we could have a distance to contiguity  
option for all islands.... E.g.  island counties get exactly 1  
neighbor (the closest county)





On Aug 29, 2005, at 5:27 AM, Alfred Nucci wrote:

> Thanks for email last night (actually several  nights ago) and url  
> for obtaining the latest (beta) version of stars. Using the beta  
> version of STARS allows me to read in example project and to create  
> a project.   However ...
>
> After trying to read in my county file a few times with project  
> maker app -- this is a real improvement over previous version -- I  
> was successful in creating a stars project.  Now I confront the  
> more mundane issues of what to do about "islands" -- this is an  
> issue when I try to create a contiguity file (queen) after bringing  
> the stars project into the main stars software.
>
> I have encountered similar problems with geoda -- although the  
> default here is to create a *.gal file where an area (s) has 0  
> neighbors. I turned to latest version of arcgis to "clean" those  
> areas' geography with polygon slivers -- the result of dissolution  
> of county boundaries --  and geoa produces a much improved version  
> of a *.gal file, although there remain four counties on the  
> mainland that are islands. Apparently, the stars software does not  
> have this option and does not create a *.gal file.

Even if you have islands, ProjectMaker should create a gal file.  Are  
you saying that it isnt?  If the project is bombing in stars because  
of a bad weights matrix, then you can edit the *.prj file and delete  
the line under [weight]:
gal: states48 (E.g., kill this line and you should be able to at  
least start the project in STARS)


>
> Al Nucci
>
> ps.  I tried to use the geoda *.gal weight file with appropriate  
> modications in stars but was unable to do so.  Is this because of  
> the island issue noted above or other difference between geoa and  
> stars weight files (aside from first line which I changed and the  
> use of a records counter rather than stfips code.,)

Our accounting system for cross-sections is probably different than  
geoda.   I.e. observation 0 in geoda is probably not 0 on STARS.   
Ours goes in the same order as the *.dbf file.  I am not sure about  
geoda.


Please let me know if this helps, or if their is anything else I can  
do....




Mark Janikas,  IRSR
Department of Geography
San Diego State University
5500 Campanile Drive
San Diego, CA 92182-4493
619-594-8032
ja...@ro...




>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle  
> Practices
> Agile & Plan-Driven Development * Managing Projects & Teams *  
> Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/ 
> bsce5sf
> _______________________________________________
> Stars-py-users mailing list
> Sta...@li...
> https://lists.sourceforge.net/lists/listinfo/stars-py-users
>

[STARS] thanks for beta stars -- now onto geography questions

[Alfred N. <Alf...@ce...>]

Thanks for email last night (actually several  nights ago) and url for 
obtaining the latest (beta) version of stars. Using the beta version of 
STARS allows me to read in example project and to create a project.   
However ...

After trying to read in my county file a few times with project maker 
app -- this is a real improvement over previous version -- I was 
successful in creating a stars project.  Now I confront the more mundane 
issues of what to do about "islands" -- this is an issue when I try to 
create a contiguity file (queen) after bringing the stars project into 
the main stars software.

I have encountered similar problems with geoda -- although the default 
here is to create a *.gal file where an area (s) has 0 neighbors. I 
turned to latest version of arcgis to "clean" those areas' geography 
with polygon slivers -- the result of dissolution of county boundaries 
--  and geoa produces a much improved version of a *.gal file, although 
there remain four counties on the mainland that are islands. Apparently, 
the stars software does not have this option and does not create a *.gal 
file.

Al Nucci

ps.  I tried to use the geoda *.gal weight file with appropriate 
modications in stars but was unable to do so.  Is this because of the 
island issue noted above or other difference between geoa and stars 
weight files (aside from first line which I changed and the use of a 
records counter rather than stfips code.,)

Re: [STARS] error message -- Tkinter again

[Serge R. <se...@ro...>]

On Fri, Aug 26, 2005 at 10:22:33AM -0400, Alfred Nucci wrote:
> Hi Serge,
>=20
>    I followed your advice and downloaded the installer for the beta=20
> (next) verion of stars. Now I am able to  open the california stars=20
> project distributed with this package.
>=20
>     However, although I am able to create a stars project from a county=
=20
> file (n=3D3065) with  four population growth mesures for 60-70, ...,=20
> 90-00, the   log from stars.exe.log suggests otherwise
>=20
> Exception in Tkinter callback
> Traceback (most recent call last):
>  File "Tkinter.pyc", line 1345, in __call__
>  File "starsgui.py", line 1702, in openProject
>  File "stars.pyc", line 197, in ReadProjectFile
>  File "stars.pyc", line 386, in ReadData
>  File "Data.pyc", line 204, in __init__
>  File "Data.pyc", line 37, in cs
> ValueError: total size of new array must be unchanged
> Exception in Tkinter callback (this is attempt to shapefile in stars as=
=20
> starts project dumb but testing)
> Traceback (most recent call last):
>  File "Tkinter.pyc", line 1345, in __call__
>  File "starsgui.py", line 1702, in openProject
>  File "stars.pyc", line 175, in ReadProjectFile
>  File "ConfigParser.pyc", line 263, in read
>  File "ConfigParser.pyc", line 456, in _read
> MissingSectionHeaderError: File contains no section headers.
> file: D:/data/arcview/USA/pop6070809000_wakhi_short_250805.prj, line: 1
> 'GEOGCS["GCS_Assumed_Geographic_1",DATUM["D_North_American_1927",SPHEROID=
["Clarke_1866",6378206.4,294.9786982]],PRIMEM["Greenwich",0.0],UNIT["Degree=
",0.0174532925199433]]'

i think the problem may be that the "wrong" project file is getting
read, as the first line of the stars project should not look like the
line listed above in the traceback. in other words there may be an
ArcView prj file (with projection information)  that is being read as oppos=
ed to the stars project
file you created with projectMaker.

so a couple of things to check. how many *.prj files are in the current
directory? if there are more than one, you want to open the stars prj
file, which is likely the more recent of the bunch.

can you send me (off-list if you prefer) the prj file that is created? that=
 way i can
see better what is going on.

let me know if this helps.
s.
--=20
Serge Rey	http://geography.sdsu.edu/People/Faculty/rey.html
Replacing things with a bar is a familiar experience from the city
centre of my home town, Newcastle upon Tyne.
 -- Peter Stephenson (A User's Guide to the Z-Shell)

[STARS] error message -- Tkinter again

[Alfred N. <Alf...@ce...>]

Hi Serge,

    I followed your advice and downloaded the installer for the beta 
(next) verion of stars. Now I am able to  open the california stars 
project distributed with this package.

     However, although I am able to create a stars project from a county 
file (n=3065) with  four population growth mesures for 60-70, ..., 
90-00, the   log from stars.exe.log suggests otherwise

Exception in Tkinter callback
Traceback (most recent call last):
  File "Tkinter.pyc", line 1345, in __call__
  File "starsgui.py", line 1702, in openProject
  File "stars.pyc", line 197, in ReadProjectFile
  File "stars.pyc", line 386, in ReadData
  File "Data.pyc", line 204, in __init__
  File "Data.pyc", line 37, in cs
ValueError: total size of new array must be unchanged
Exception in Tkinter callback (this is attempt to shapefile in stars as 
starts project dumb but testing)
Traceback (most recent call last):
  File "Tkinter.pyc", line 1345, in __call__
  File "starsgui.py", line 1702, in openProject
  File "stars.pyc", line 175, in ReadProjectFile
  File "ConfigParser.pyc", line 263, in read
  File "ConfigParser.pyc", line 456, in _read
MissingSectionHeaderError: File contains no section headers.
file: D:/data/arcview/USA/pop6070809000_wakhi_short_250805.prj, line: 1
'GEOGCS["GCS_Assumed_Geographic_1",DATUM["D_North_American_1927",SPHEROID["Clarke_1866",6378206.4,294.9786982]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]]'


Log when I try to read this project as stars project is:

640x512+0+0
Exception in Tkinter callback
Traceback (most recent call last):
  File "Tkinter.pyc", line 1345, in __call__
  File "ProjectMaker.py", line 182, in openSTARSProject
  File "ProjectWorker.pyc", line 54, in __init__
  File "ProjectWorker.pyc", line 83, in useExisting
  File "ProjectWorker.pyc", line 971, in __init__
  File "stars.pyc", line 197, in ReadProjectFile
  File "stars.pyc", line 385, in ReadData
  File "Data.pyc", line 397, in __init__
IndexError: list index out of range

If you see something obvious send my way.  I am going to try to create 
this file a few more times -- one never knows.

Al

Re: [STARS] tinker not working

[Serge R. <se...@ro...>]

On Thu, Aug 25, 2005 at 04:05:22PM -0400, Alfred Nucci wrote:
> Greetings!  My name is Alfred Nucci and I am a researcher at US Census=20
> Bureau Center for Economic Studies.=20
>=20
> I am new to STARS project and think the idea is a good one! So I=20

hi al,

thanks for your interest in STARS!

> downloaded the 'made for dummies" windows executable to my windows 2000=
=20
> pc and set about doing things spatial. I discovered that I was unable=20
> "import" California arcview shapefile data distributed with this=20
> software using the "projectmaker" procedure; I received the following=20
> error message
>=20
> Exception in Tkinter callback
> Traceback (most recent call last):
>  File "Tkinter.pyc", line 1345, in __call__
>  File "ProjectMaker.py", line 1369, in createIdsAndNames
> IndexError: list index out of range
>=20
> I verified that  STARS itself worked in the sense that I could include=20
> the project on personal income, part of the distribution, printing=20
> variables values, id's, plots. I folllowed the guidance in a list email=
=20
> and verified that dbfdump.exe works although shpdump.exe does not.

we are close to releasing a new version of stars and projectMaker that
should take care of any path problems. if you want to "kick the tires"
on what the new release will look like, you can download a windows
binary installer from:

http://loess.sdsu.edu/~serge/stars/pub/setup.exe

warning, this is not fully tested and isn't a formal release yet as we
are trying to finish up a more detailed Quickstart guide, that hopefully
will be done in two week's time. we would appreciate any feedback users
may have on the new release candidate in the binary.

there is a new projectMaker binary that will be installed if you run the
above setup.exe. it will reside in the location the setup program
installs the stars binary (default c:\Program Files\stars).  that should
work without any of the path problems you are running into with the
previous version.

we will try to get a draft of the Quickstart guide out shortly to get
feedback from users (and maybe enlist anyone who wants to join the
effort!).

>=20
> After some fussing around, I was able to obtain most recent versions of=
=20
> Python and Numpy and  after uninstalling STARS I downloaded the windows=
=20
> version of STARS that is not packaged as an executable and received same=
=20
> error message when I tried to read the California shapefile. So I joined=
=20
> the list and I am sending this off.
>=20
> The only part of this that makes me suspicious is that my windows system=
=20
> is located on drive c: while the stars, python, numpy software is on=20
> d:.  I seem to remember from some email that there may be a device=20
> conflict here, no?

try the binary above. i'll roll up the source for a formal release in
the coming weeks.

we have been very busy adding features but should have done a better job
of keeping users up to date on what was coming down the pike.

we'll be announcing the formal release in a couple of weeks on the list.


let me know if there are any questions.

thanks,

s.

--=20
Serge Rey	http://geography.sdsu.edu/People/Faculty/rey.html
You think you know when you learn, are more sure when you can write,
even more when you can teach, but certain when you can program.
 -- Alan Perlis=20

[STARS] tinker not working

[Alfred N. <Alf...@ce...>]

Greetings!  My name is Alfred Nucci and I am a researcher at US Census 
Bureau Center for Economic Studies. 

I am new to STARS project and think the idea is a good one! So I 
downloaded the 'made for dummies" windows executable to my windows 2000 
pc and set about doing things spatial. I discovered that I was unable 
"import" California arcview shapefile data distributed with this 
software using the "projectmaker" procedure; I received the following 
error message

Exception in Tkinter callback
Traceback (most recent call last):
  File "Tkinter.pyc", line 1345, in __call__
  File "ProjectMaker.py", line 1369, in createIdsAndNames
IndexError: list index out of range

I verified that  STARS itself worked in the sense that I could include 
the project on personal income, part of the distribution, printing 
variables values, id's, plots. I folllowed the guidance in a list email 
and verified that dbfdump.exe works although shpdump.exe does not.

After some fussing around, I was able to obtain most recent versions of 
Python and Numpy and  after uninstalling STARS I downloaded the windows 
version of STARS that is not packaged as an executable and received same 
error message when I tried to read the California shapefile. So I joined 
the list and I am sending this off.

The only part of this that makes me suspicious is that my windows system 
is located on drive c: while the stars, python, numpy software is on 
d:.  I seem to remember from some email that there may be a device 
conflict here, no?

Thanks,
Al Nucci

[STARS] Gouranga

[Neateye <nit...@ao...>]

Call out Gouranga be happy!!!
Gouranga Gouranga Gouranga ....
That which brings the highest happiness!!

Re: [STARS] Question: Merging Data in ProjectMaker

[Serge R. <se...@ro...>]

On Wed, Apr 13, 2005 at 11:36:03PM -0700, Boris Dev wrote:
> Hi.
>=20
> I apologize ahead of time if the question is based on
> me missing the new developemnts around ProjectMaker in
> recent CVSed STARS.
>=20
> Two issues.
> -----------------------------------------
> A. steps I do to experiment:
>=20
> 1) I open STARS/SRC/ProjectMaker.py
> 2) Then to experiment I open STARS/SRC/DATA/csii.prj
> from "Open STARS Project" Menu item.
> 3) I try to "Plot Shapes" and ProjectMaker doesnt seem
> to work
> 4) common error seems to be "No ArcView Project"=20
>=20
> -------------------------------------------
>=20
> B. steps I ulimately want to do (data is attached):
>=20
> 1a) Merge the file named:
> 123.Countries.WDI.GDP.PPP.Capita.csv=20
>=20
> 1b) into the currently working STARS Project:
> world_selected.prj
> --------------------------------------------


boris,

you should definitely pull out the current version in the cvs as the new
code for making projects is much more robust and user friendly.
it will allow for creation of a project and the merging of additional
comma delimited files.

alternatively, if you send us your data we can build the project for you
- as well as test the new code prior to the pending release (which
  should be in the next few weeks).

s.

--=20
Serge Rey	http://geography.sdsu.edu/People/Faculty/rey.html
Get a bicycle. You will not regret it, if you live.
  -- Mark Twain, Taming the Bicycle

[STARS] Question: Merging Data in ProjectMaker

[Boris D. <bor...@ya...>]

Hi.

I apologize ahead of time if the question is based on
me missing the new developemnts around ProjectMaker in
recent CVSed STARS.

Two issues.
-----------------------------------------
A. steps I do to experiment:

1) I open STARS/SRC/ProjectMaker.py
2) Then to experiment I open STARS/SRC/DATA/csii.prj
from "Open STARS Project" Menu item.
3) I try to "Plot Shapes" and ProjectMaker doesnt seem
to work
4) common error seems to be "No ArcView Project" 

-------------------------------------------

B. steps I ulimately want to do (data is attached):

1a) Merge the file named:
123.Countries.WDI.GDP.PPP.Capita.csv 

1b) into the currently working STARS Project:
world_selected.prj
--------------------------------------------
Thanks!
Boris