[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [udig-users] Automatically updating a field in a set of selected records
|
On 02/02/2011, at 6:50 AM, Michael Goldstein wrote:
> Can you perhaps point me to the right features in uDig? I'm starting up a new project, and feel that uDig is the best open-source tool for what I need to do IF I can figure out how to implement the last step.
Question for you; are you doing this work as a programmer or as a user?
> My task is to mark-up a set of stream segments in a large shape file based on reading and interpreting a paper list published by a state bureaucracy. The paper list is missing critical information that would make it easily automatable, so interpretation and human translation is, unfortunately, essential.
Okay; got it.
> 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.
> What I need to do is:
>
> 1. Search for the stream name in the attribute table. Since stream names are rarely unique, even within a single watershed, I have to muck around visually a bit to make sure I've got the right segment(s) identified by checking out the next-order streams, the basins, etc. It's made worse by the fact that the shape file isn't perfectly coded, so sometimes the right stream flows into an "unknown stream", and I can only confirm the name of the second order stream (and by extension confirm the identity of the subject stream) by scanning up and down segments of the next order stream until I find one with a recorded name.
You can use the table search facilities to look for the feature you are interested; given the amount of manual work involved I personally would be tempted to create a few more operations like "select next-order stream" to aid in the review process.
> 2. Select all of the features which correspond to the reach in the list. I can usually construct a simple query to do this, using various attributes in the table, once I've visually confirmed it's the right one.
Seems like you are on top of this.
> 3. [THIS IS WHERE I NEED HELP] Set a flag in one field of each record selected in step 2 to mark the reach. The "flag" is an alphanumeric code, 2-4 letters long, e.g. 'DUIV'. Ideally I'd like to edit all of the records automatically, as in an update query. Grass, for example, has a function that lets me do this but the GRASS UI is overwhelmed by steps 1 & 2 for such a large dataset. Of course, sometimes there will be only one or two features that need flagging, in which case editing it directly in uDig's table editor would be faster.
So what you are looking for is a "bulk edit" of some sort. I have been thinking of how to do that and am willing to add it to the app.
I was thinking bulk edit would work a bit more smoothly if the selection was represented as "checkboxes" (as that is easier than asking people to hold down shift); and then changing a field in one of the "marked" features would be applied to all.
What do you think? Is that a good plan...
> I suppose, based on the "marketing" docs I read, that it should be possible to set up a project where the attribute table for the layer was maintained in MySQL, and I could use update queries in PHP MyAdmin to execute the changes. I have little confidence that I could set this up properly, especially as I want to use uDIG's table view and search capabilities at the same time.
>
> 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"?
> As you have no doubt gathered, I'm a data analyst, not a programmer. I can construct simple SQL queries, but that's about as much as I want to do in terms of creating code.
> Any thoughts you have would be appreciated.
> Michael
>
Thanks for the question and idea; Let me know what you think of the "bulk edit" idea; does it match what you are thinking of with respect to "internal update" ?
Jody