Hi Rolando,
Sorry for the late reply, I somehow overlooked your message.
Both search and query are useful features but the results table feels
a little crammed on the right-hand side, especially on my laptop. Have
y'all considered attaching the table along the bottom instead? For
example: http://projects.opengeo.org/geoext/wiki/GeoEditor
I'll bring up that suggestion with Ben, sounds good to me. Another idea
is to make the side tab for the results wider by default.
Also, can you please point me at the interface for defining attribute
titles? I can't seem to find it.
The interface for specifying attribute titles is at the bottom of each
layer's 'update description' page. There is a table showing each
attribute name, along with an editable text field for changing the
attribute title (it defaults to the attribute name) and a checkbox for
determining if the field should be searchable (disabled for
non-character fields). Soon we want to add a way to specify a sort
order for displaying the attributes in the map results panel. There is
a new LayerAttribute model to store this info, and it's populated during
layer upload. In terms of displaying the attributes on the map, there
is a new Javascript file to do that in the geonode-client project:
GeoExplorer/FeatureQueryTool.js
- Display layers in a category tree
- Allow renaming and drag/drop of layers and categoriesThe
categories are useful, especially when creating maps with lots of
layers as is the case with the BostonMap or AfricaMap. Could you
please point me at the interface for creating and managing
these categories? Are they only generated based on the addition of
new layers and then modified from there?
When a layer is added to the map, the category it appears under
initially is the 'topic category' field from the Layer model (or
'General' if the topic_category is blank). The layer categories
available come from a new LayerCategory model. However, once on the
map, the category's name for that particular layer and map is stored in
the MapLayer model (the 'group' field) and the order of categories in
the tree is stored in the Map model (the 'group_params' field). Those
are all passed along in the 'config' JSON for the map.
- Metadata link on layer properties window which redirects user
to that layer's description page
This is a good idea and we should implement in GeoNode as well. I'd
suggest opening in a new tab or window though, to avoid losing unsaved
changes to the map.
I will probably be working on just that very soon. Right now I'm
working on adding the data search and upload pages as tabs in a new
window on the map page. You can try it out now at
http://worldmap.harvard.edu/test but it still needs some work. For
example, the map's 'beforeunload' event stops working after the
BoundingBoxWidget is rendered in the window.
For our reference: http://dev.geonode.org/trac/ticket/920
- Display Picasa and YouTube feeds based on keywords assigned by
the user
It took me a while to figure out what the Picasa and YouTube feeds in
that little "More..." menu were all about. What was the motivation for
creating a separate menu for what are essentially point layers instead
of creating a "More..." (or "Social Web" or whatever) cateogry in the
layer tree? This could also solve the weak connection between the
field for defining keywords (in the map properties/metadata) and the
layers themselves as Picasa or YouTube specific settings could be
handled (independently) as layer properties.
Eventually we do want to treat those feeds as just another kind of
layer, and allow users to add other georss feeds as new layers. But
this was just the best I could come up at the time given the deadline
for including them and my initial unfamiliarity with the geonode code.
- Introductory window on first visit to any map, with
content determined by the map owner.
Great idea, we should implement that as well to provide viewers with
some context. I assume this is populated with the title and abstract
from the metadata? I noticed that it still shows up when no
description has been provided—you may want to make it conditional on
their being content to show.
Actually that is populated from a title field and text area (which has
some default content) on the 'Save' window. I agree that it would be
better to show it only if the user has something specific to put there.
For our records: http://dev.geonode.org/trac/ticket/922
- Assign layer/map access permissions to users by email
address instead of existing username: create accounts for the
addresses if they don't already exist and send an email with their
username and temporary password
This is a nice idea and we should extend our permissions system
(http://dev.geonode.org/trac/ticket/864#comment:4) to allow for email
addresses. We've also thought of something similar for our future
groups workflow
(http://dev.geonode.org/trac/wiki/Groups#a3.ManagerView). One question
though, do you allow users to register multiple email addresses to
their user account or is it a one-to-one relationship? It would
perhaps be useful to allow users to register multiple email addresses,
select a primary for notifications, and allow for some method of
duplicate account resolution from the user profile
(http://dev.geonode.org/trac/wiki/UserProfile) to prevent the
proliferation of accounts.
Right now each user can only have one email address. I think in geonode
it's possible to register the same email address more than once? But in
worldmap I'm forcing all users to have a unique email.
For our records: http://dev.geonode.org/trac/ticket/919
The project is still in the alpha stage and there are plenty of
kinks to work out, but feel free to check it out if you're
interested - you can visit the website at
http://worldmap.harvard.edu/alpha, it's currently running on
Amazon Web Services. The code is also available at
https://github.com/cga-harvard/cga-worldmap. Any feedback you
can give would be much appreciated.
I'm also told that y'all need ways of managing permissions through the
map composer. My suggestion would be extend the Map Properties and
Layer Properties dialogs with Permissions tabs that included forms
(editable for managers, uneditable for plebes) for managing permissions.
Good idea, I'll probably be working on this soon.
