[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[udig-devel] Service Workflow
|
Looks like we got two ideas going on:
1. Import / Export is being used because the data is being managed
outside of uDig. In the case of import we are connecting to an existing
file, service, etc. The idea of the service being added to the catalog
is independent of its existence. For export we are taking data from uDig
and giving it to an external file or service to manage.
2. New Layer looks to be a mistake; if we view a layer as simply adding
some structure to an existing Map an add layer action will suffice.
If you turn back the clock to uDig 0.8 you would see that everything
used to be done in the new wizards. Furthermore add Layer should have
the following options:
a- from the catalog (ie quickly find and select from known services)
b- import from an external service (ie current workflow)
c- from a new feature type (ie current create Feature Type action)
3. New Wizards - our new wizards have been reduced to simple button
clicks now; at least they are limited to uDig managed content. Creating
a new wizard for FeatureType will help address this lack).
We used to demand both a known GeoResource and the selection of a style;
we have whittled that away by creating a style based on the resource
selected. Since the majority of people are assembling a new map from
scratch (b) above has been stressed into prominence. Using the catalog
to attempt (a) is a bit of a mess since exploring the tree breaks down
once you have a few hundred layers loaded.
Switching over the to search view (and limiting search to the local
catalog) is a much more efficient way to work - but I don't think many
people have discovered that?
Jody
Adrian Custer wrote:
SERVICE:
-------
Your "service" workflow is wrong or sloppy because it suggests that
"Import..." and "Export..." are parallel ideas. We have taken over
eclipse notation but it doesn't work for us since the actions are so
different:
1. Import... = add, into the catalog, a link to a service
2. Export... = dump, into the service, a data set
Note the first should always succeed (although we may not be able to
actually 'import' any data from it) while the second may cause a myriad
of issues such as filling disks, violating permissions... The lack of
parallelism and precision here, I think is part of the confusion in the
UI which I described to you in my separate mail: e.g. "New Layer" which
is really "Add a service link to the catalog" rather than the "Create a
blank layer to work with" one would expect in parallel to "New project"
and "new map".
I would argue strongly in favour of bringing the notion of "service" to
the fore and having a "Link to data service" menu entries or tooltips
and then representing these services in the catalog.
******************************************************************
BTW, this would start the process of greatly improving the
catalog for user friendliness and power
Catalog = list of services
Services = UI elements with info (so requires a better
widget)
Type -> file/db/web
User Rights -> read-only, write
Access -> yes /no (the latter *are* the web
catalog which is merely a list of services which
have not yet been accessed)
Access this session -> yes, no
Last access time
Result of last access
Coverages = UI elements contained in a service
This richer catalog would allow us to drag and drop data sets
("Coverages") onto services to copy them / transform their
schema. I use "Coverages" obviously in the vector sense and
because it's much simpler a problem to handle than any source of
Data. I don't think this 'rich catalog' is really straying into
the realm of 'resource management' although it is admittedly
getting close. This is definately out of your scope but doesn't
seem particularly hard and would be a *big* win for udig.
********************************************************************
all for now, it's time for lunch,
--adrian
