Re: [udig-users] Automatically updating a field in a set of selected rec

[Michael Goldstein <michael.goldstein7@xxxxxxxxxxx>]

Jody:

As a user, you always want to know the state of your data and whether it's "safe".  We're all used to applications where we open a file, do an operation, and then save the file (and until you "save" it, it's not "safe").

To me, that's the metaphor one wants to preserve in any kind of file operation.  I guess it's a substantial challenge in uDig because you have so many different kinds of data sources.  But somehow if you could keep the metaphor of "saved"/"not saved" in the forefront, I think it's powerful.

Generally, I'm loading data off a .shp file.  Frankly, I haven't used uDig enough to suss out how it preserves my data when I save a project.  Does the data end up back in my shapefile?  Or does it end up in a project file somewhere?  For what it's worth, GRASS has vector layers which you have to explicitly export to a shapefile if that's how you want to save it.  I believe that the project files will save a GRASS vector layer even if you don't export it.  However, in what I do, which is typically manipulate a single file at a time, I'm not interested in saving the project, so I've always saved the shp file.

In MapWindow, when you do an operation like extract data from a query, you are forced to save the result into a new shapefile.  It then prompts you if you want to load it into your workspace as a new layer.  This has the advantage of being clear... I always know where my data stands.

OK, with this in mind, you asked my input on reshape.  So here it is.

First, reshape ought to be a function available in the table editor.   IMO, that's the natural place to look for a set of operations on a table.  The reshape operation is always on the dataset I'm viewing in the table.  If you want to make the same capability available from the catalog, that's OK, I guess. 

Second,  give me a clue about what I'm supposed to do in the reshape window (i.e. a prompt about adding CQL statements).  Being able to lookup the syntax of those statements (as in the MapWindows field calculator) is nice but not critical.

Ideally, when I do an operation, uDig would simply perform the reshape, and reload the reshaped data table with the data in view.  It would be the "same" resource, as far as the user is concerned.  It would follow the same rules for saving as any other edit.

If that can't be done automatically, then less desirably you could have throw up a new dialog after the user clicks OK (or else show them as a set of options on the bottom of the reshape window before they click)... something like:

Reshape will create a new data structure from the current table:

[x] Copy data from existing table into new structure
[x] Save new structure and data
[x] Load new structure and data as a layer in the current project
[x] View new structure in the table editor

What happens next would depend on a few things including what you checked and the type of resource you're dealing with.  If the original dataset is a shp file, it's easy enough to save it as another shp file.  If you're linked to an external DB or a geo server, I guess it would save the table there or would prompt you to save it locally in a new .dbf file if you didn't have write permission for the external server.

Thanks for you interest Jody.  I'm quite sure I'm NOT a typical GIS user, though I suspect my needs are a small subset of what a general user might need.  

Regards,
Michael


On Feb 5, 2011, at 5:35 AM, Jody Garnett wrote:

> 
>> While I'm at it, I have to say that while there are many admirable aspects to uDig, I find the reshape wizard is not one of them.  I tried to add a column to a file.  The idea that you create a scratch file, and then save the resource while unchecking the scratch file you just created, is about the most confusing sequence of operations I've ever experienced in a software package.  Anyway, just my $0.02.  
> 
> No worries; for "Reshape" it was mostly a programmer teaching device that was too useful to leave out of the application. I would love to put a nicer user interface on top of it.
> 
> As for "scratch" files; that is a bit more of a general purpose idea. Giving people a chance to try out what they have done without being forced to save it all the time. The scratch file should be removed after it has been saved (right now when you save any maps that referred to the scratch layer are updated to point to the final location).
> 
> Can you think of an more appropriate sequence of events?
> 
>> Thanks for your interest and patience.  I am extremely pleased that the uDig community exists, and I wish you every success with it.
> 
> No worries; my volunteer time has been pushed into making the latest release so I have not have had any time for more features myself. I hope to return to udig development towards the middle of the month.
> 
>>>> The list tells me the name of a stream, and the name of the stream it flows into, and the basin in which both are located.  The shp file is huge, with more than 80,000 features.  One stream in the printed list typically translates to 20-30 features, and sometimes more, in the shp file.
>>> 
>>> This sounds like fun data cleaning work.  IF YOU'RE A MASOCHIST.
> 
> Okay it sounds like nice honest work; data cleaning in general is rewarding in that you take information that has been collected (often at great expense) and actual produce something useful out of it - SO YOU CAN GET ANSWERS :-)
> 
> So rewarding; as oppose to debugging programming; where you do a bunch of work; so you can find out exactly how you confused things (so you can feel stupid in a new way) :-)
> 
>>>> If there were an good, internal update tool internal to uDig, I'm sure that would be preferable to phpMyAdmin....
>>> 
>>> Not quite sure what you mean by "internal update tool"?  MY WORRY IS THAT IF I CHANGED DATA USING SQL QUERIES IN MYSQL (I.E. EXTERNAL TO UDIG) I WOULDN'T THEN BE ABLE TO SEE THE CHANGES BACK IN UDIG.  YOUR BULK UPDATE TOOL WOULD BE "INTERNAL" TO UDIG IN THE SENSE THAT I MEANT.  
> 
> Oh; uDig does not have an internal (except for the one case of "scratch" layers). When you change things using the user interface they are held on a MSQL transaction. When you commit it goes back to your database. If you use SQL to hack at your database the results should change in the map display right away (well if you hit refresh); and you may need refresh the table view as well.
> 
> But yeah; udig tries to operate directly with your source data all the time; not loading it into memory.
> 
> Jody
> 

**************************************
Michael Goldstein
(609) 638-3250 (mobile)