[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [udig-devel] Feedback on 1.1M3
|
Adrian Custer wrote:
Hey all,
Fantastic work on uDig! It's really rocketing along. I'm hoping to get
back into learning/documenting the code base and started playing with
1.1M3. I ran into several issues that I am not sure are bugs so I'm
spamming them to the list.
1) Memory usage:
When playing with a 150MB data set,
http://www.ngdc.noaa.gov/mgg/shorelines/data/gshhs/version1.3/shapefiles/gshhs_land/gshhs_land.shp
uDig's memory seems to climb steadily when it renders a map or a new
layer. The eventual result is that the JVM crashes. This machine is an
old Penitum III with 512mb of ram. Perhaps one of you can try displaying
this layer on two maps and tweaking the styles to see if uDig is doing
what it's supposed to be.
This was reported and is fixed on trunk. It was part of the pains of
switching over to SWT where even images have to be disposed.
2) Styles for elevation:
I want to shade a series of polygons different colours according to the
"ELEV_MIN" field and am puzzled by the "number of classes" field. I
obviously want the number of classes to be the number of unique values
in the field. I also want a nice gradient from green to yellow to brown
to white---a classic elevation setup. I found a style that's close to
what I wanted but it's only got nine classes. Am I doing something wrong
or is this simply due to the initial state of the styling functionality?
3) A "georeferencing" view:
In playing with data obtained from different sources we often throw the
data at a map and try to see where it comes out. With data in different
projections it could be that one whole layer is a point and very far
from another. It would be amazing to have a view in uDig with an
embedded map of the world and the ability to show bounding boxes with
labels for each of the elements in the catalog. I can forsee all sorts
of problems with this but for the simple case of a number of files on
disk, the view could show the relative positioning of files and show
files that are obviously in a completely different register that uDig
does not understand how to translate. Also, showing where one's data is
compared to a base map of the world is a function that all of my fellow
biologists need. I imagine we could include a minimal set of world data
with uDig that would at least get users started.
4) Sync of project state/workspace contents:
The names of project elements (maps) in the workspace do not get updated
when the maps are renamed. This causes an unfortunate skew in project
state/what's visible in the workspace and makes debugging/understanding
what's going on harder than it could be. I think I've talked about this
before and had it rejected but I don't like it. :-)
Its not rejected it is sidelined for more important issues.
5) Renaming the common paths to lots of resources:
This is a pet peeve from my shapefile days. GeoData is huge and
occasionally needs to be moved around on disk. When a bunch of
shapefiles are moved, the references in the catalog break. This leads to
several issues:
5.1) Maps silently fail to display contents
5.2) Drag of catalog contents onto a new map silently fails.
Compare the error box that pops up on right click of the catalog
entry "add to current map".
5.3) There is no way to select a bunch of files and tell uDig
they all moved to a new base location. Ideally, uDig would note
on startup that a bunch of catalog resources with similar paths
are not accessible and ask the user if they want to retarget
their origin.
Low priority but, when needed, this kind of functionality makes a user's
experience so much better.
I agree with jody this is not low priority. Thanks for the review.
