Thanks for the super awesome feedback - it's incredibly helpful to reflect this back to the project. So many people just use the software and don't realize that a write up like this can greatly influence things. Often it's just reiterating things we already know, but it still helps greatly in prioritizing what to work on, as there's always a long list of things to do. And indeed there's a whole lot of work that's been done on branches, that isn't yet back in to the GeoNode core, so seeing the pain points does help in deciding which of those to bring in first.
Some responses inline: On Wed, Feb 1, 2012 at 8:20 AM, Reinier Battenberg < [email protected]> wrote: > Hi, > > > ... > With this setup, we experienced the following issues. We are aware that > there > is a brandnew version soon to be released, and that some of the issues > mentioned could very well have been solved already. Still, for people who > would like to train in similar conditions, this might be worthwhile: > > - Not suprisingly, we had performance issues. We had most performance > issues > on the first day. Especially in the morning, when we althogether uploaded > shapefiles. Processortime on the server maxed out at 400% and kept there > for a > long long time. A second factor might have been the slow internet > connection > and the overload of timed out http sessions to the Internet and the > Geoserver > that used all resources on the Wireless Router. The router didnt have any > statistics, so this was not so straightforward to diagnose. (tip: use WRT > on > your wireless router) > After lunch, when we started on creating maps and styling them, the system > became much more responsive. > > In time I would like to see us do more testing and improvement on performance stuff, so we could get GeoNode running in more constrained environments. First focus has just been on getting the functionality working, but it does sound like some profiling on resource constrained machines might lead us to find some places for improvement. > - During the styling session people created their own maps, and started > styling layers. During this exercise at some point, layers that where > shared > between maps got corrupted. People might have edited eachothers styles > (they > looked very similar), but what surely happened was that 2 layers lost their > default SLD in geoserver. This renders some pages in geonode useless and > causes all sorts of errors. Going into geoserver and assigning a (pretty > random) default style to the layer fixes this. > > Are you able to reproduce this bug? Sounds like a serious one, and if you could find a way to do it consistently then the developers may have a decent chance of fixing it. I think the ownership / permissioning around styling may not work great, and may take a deep solution, but it'd be good if we can reproduce the common case, and maybe get a quick workaround that doesn't lead to things breaking. > - On other geonode installations we had already seen that sometimes when an > upload fails, a geonode layer might be in the geonode database, but is not > present in geoserver (the whole table is missing). I think Jude is working > on > some code to straighten this out when it happens. Would be great if an > admin/user could do this from the geonode gui. > > Cool, if Jude doesn't have this worked out then it could be good to file a bug to keep track of it. > - On the second day, we brought a second server. It ran fine for about 30 > minutes, then there was a powersurge (yeah, those happen in Uganda.) After > the > power came back, tomcat would not finish starting. The attached > catalina.out > sample shows the full startup sequence. The server never finishes indexing. > Could it be that: > -- the indexing is not 100% necessary during training? > -- the indexing is causing the very high load during uploading data > sessions? > If so, is there a way to switch off the indexing? That would save a lot of > trainers in locations where you can not use "the cloud" during training > sessions a lot of headaches of running around with server-size hardware. > > What indexing are you talking about? Reading that log I'm not sure I see the line you're talking about that indicates the server not finishing indexing. The line that concerns me is the 'Couldn't create user preferences directory. User preferences are unusable.' Right after the epsg creation I think means it might have failed to create the epsg database. > Enough about problems. At the end of the second day, we workshopped around > uses of geonode, and one of the questions asked was: How could geonode be > improved? > > The top 5 was: > > 1. More data analysis tools > Any chance you could flesh this out? What types of data analysis tools? And do you want these to output in to new layers, or to just do render things differently on the current layer? Do they need a GUI to do this data analysis? Our first data analysis step, at least in GeoServer, is to add WPS and GeoScript, though that will be pretty programmer heavy. If there are some subset of operations that you see being important for some basic analysis that'd be good to know. > 2. display attribute table > How are you imagining this working? Like in a grid? Try the 'query' functionality on http://sfpark.demo.opengeo.org/SFPark/ and let me know if that comes close to what you're wanting. I've also been thinking of making a feature grid available by default on each layer's Data page. So people could see not just the data on a map, but also look at what attributes are there. > 3. enable layer grouping > You mean like on the layer tree? To be able to select a few layers and then sort of squash them in to one layer, which then makes just one WMS request? Do you want that layer group persisted on the server and available for others to request through the WMS? Or just on a map level, where it'd just make a multi layer WMS request. > 4. connection to social sites like facebook and linkedIn > This (and a whole lot more) is on the social features branch that is planned for 1.2. And they're in the ANZSM, see the prototype at http://spatialmarketplace.net.au/maps/13 You can like or +1. No linkedin yet - I agree that in many ways that's the social platform that makes the most sense, but I think they don't have easy to use API's. > 5. minimise error bugs. > > Can you describe what you saw? It's hard to minimise in the abstract, need to address the most common cases. > And in random order the rest of the list was: > > Improve tools for styling > more admin control in user editing > application compatibility > include a timeline for map edits > include print layout > ability to download backdrop for a region(facilitates for offline) > use standard GIS terms > make it easier to make groups > help feature for frequently asked questions > having the legend directly on the map. > > These are all interesting, and at some point it'd be good to flesh some of them out more, but I'm already asking you a bunch of questions, so will hold off. > These are the raw items, they also tell something about the training we > did. > We did not cover the printing part, some people might have missed the > current > legend, we later showed some advanced users how to load peoples own styled > WMS > layers in ArcGIS & QGIS (to the exitement of the trainees). > > And, while at it, maybe i could at 2 of my personal favorites (Withouth > knowledge of 1.2): > - Import Geoserver layers into Geonode. This is especially useful for very > big > geotiffs and for remote WFS layers. > You mean like from a remote GeoServer? Or just being able to configure the GeoNode's GeoServer directly and then have GeoNode updated to be aware? I _think_ the later may be possible, with some geonode django command to update layers. But someone more knowledgable will have to sound in. The former is a feature that ANZSM is working on. Remote WFS layers don't work that well because cascading is so inefficient (I randomly wrote a paper about this and potential solutions / workarounds if anyone is interested). But remote WMS works pretty well. The map I linked to above actually is using a remote WMS - http://spatialmarketplace.net.au/data/geonode:0 I think it's actually an esri server - http://spatialmarketplace.net.au/services/69/ > - Slightly more userfriendly errormessages would be great. I know Tomcat > spits > out lists and lists of errors, but having a slight clue of where in the > process things broke helps diagnose issues a lot. > > Good to hear - we know this is an issue, and I think there have been some ideas about how to improve it. > In general, we love Geonode. Its very relevant in the Ugandan context. A > lot > of the discussion here is still about the actual sharing of data. There is > a > great level of reluctance. Using Geonode to show how easy it can become to > mix > & match data makes the advantage of sharing your data a lot more concrete > for > people. > > This is great to hear - we're obviously hoping to make it a whole lot better, but it's great to hear it already is relevant and makes a difference. If you're interested in helping out more in the community let us know. Haven't done a great job of making obvious how to help, but there's a whole lot to be done, for developers and non-developers. But even if you can't even this feedback is super great, and keep it coming when you use GeoNode more. best regards, Chris > Commercial drilling for oil is not expected to start before 2017. > > until then, > > Reinier Battenberg > > > > >
