jeffersonheard / geoanalytics Goto Github PK

We support OGR and GDAL types, but by default what are those? What about GRASS? What do people need to access these "supported types?"

Walk through creating a new resource, styling that resource, creating a styled layer

add a signal handler to handle pre_save relatedresource and update a shadow_resource handle.

use that shadow_resource to allow someone to derive rendered layers and display the RelatedResource summary page

Currently is just the same as DataResource page and will break. Fix by switching to page.relatedresource.shadow_resource.dataresource

Currently JS libraries are accessed via a mishmash of static/ and CDN hosted libraries, and there's no {% include %} snippets for common sets of JS libraries. Standardize better across the whole system which libraries are being used and provide template fragments to help users include them

Users should be able to direct semantic linkages between different Page flavors in the system.

This would take the form of

DataResource (specified as slug or URL) -> verb -> OtherPage (specified as slug or URL)

And "verb" could be defined elsewhere. The point of such a system is to be able to generate an RDF that explains the semantic relations between all the data resources in the system and deploy a system like Pyke (or Prolog) that allows people to make inferences or write robots that generally make sense of the network of data.

We could write much more thorough search engines for geographic data using this. Imagine something like this:

all data resources containing ocean temperature on 12/31/2012 which derive from http://ga.renci.org/catalog/ncfs/ocean-circulation-model

The media/uploads directory should use git to track changes when someone uploads a new version of a dataset or the system cache updates the dataset from its source.

For resources where the data file is listed as a resource_url, there is a serious performance problem that sometimes results in having to load the resource from a shell. If the resource is so large that it takes longer than the request timeout, then it will simply die.

The solution should be to fork off the compute_fields call as a Celery task or spooled task in uWSGI.

Modify get_dataframe() to accept a spatial filter. Use get_dataframe() to return features for WFS and support the writing of different OGR datatypes.

1. Problem Statement
2. The GA Solution
3. Differentiate from other projects
4. Explain code structure

Make an AJAX aware side-menu so we don't have the current issue with deep nesting for the catalog.

We need a tutorial for how to use Carto stylesheets with Geoanalytics. All stylesheets are done in Carto, but someone new to GA might not already know what carto is. Mapbox has docs, but we should provide detail

Adapt the TileMill documentation to creating a map style using map data from Geoanalytics. This involves pointing TileMill at the data source on GA and extracting a subset, then using TileMill's Carto language to create styles

ga_interactive gives the user an interactive python shell with full access to the database and underlying data and machine regardless of user permissions. Right now permissions to access it should be very very limited for this reason.

The question is, is there a way around this? I can think of several things offhand that might help:

• Sandboxing : create a chrooted temporary session so that the user can only write files / etc in a controlled way, setting sensible ulimit, etc to prevent them from taking up too many resources on the host machine.
• Don't import the django environment directly, but create a library that hands them what they need in a more controlled fashion.
• Force them to use webservices for their analysis. Has the advantage of portability with the disadvantage of being painfully slow for Big Data
• Continue to limit ga_interactive to trusted users and warn of the dangers

Add an Application data type to host a simple application on Geoanalytics

• Assemble a number of layers in order
• Assemble a set of Javascripts
• Allow optional Javascript to be uploaded and hosted.

Make better templates than the default templates for Mezzanine for pages using static and fluid layouts.

Right now, the data summary in the data page takes forever for large datasets. This is because the DataFrame object is so large.

Possible solutions:

1. cache these rendered templates
2. use an AJAX call to populate the summary with the results of as_dataframe, rather than try to do it as the page is rendering.

DataFrames where the data object is too large to fit into memory should use Pandas' HDF5 store in as_dataframe to page data to and from disk and cut down on memory use.

Same as the previous issue - make a footer menu that doesn't display everything under the sun, but rather only does the first level of pages.

Use the DataResource record to determine whether or not the resource should be tracked in the version tracker.