CSV/Excel upload

[sbenthall]

Galen request, based on potential user feedback, CSV/Excel upload and management, where the file would have Lat and Lon columns.

[jj0hns0n]

This is covered in GNIP 17

[ingenieroariel]

Leaving it open and in scope for 2.x then.

[jj0hns0n]

@iwillig @ischneider @rmarianski Since the importer now supports CSV, how much effort is required to also support XLS files?

[rmarianski]

I think we'd be able to re-use most of the front facing code from the geonode side. From the back end, I'd recommend creating just an excel file format implementation, which is much less work than creating a full datastore. It essentially amounts to parsing the format, and generating the appropriate feature type. We'd get to re-use all the same transformers too.

[ischneider]

@jj0hns0n , agree w/ the appraisal from @rmarianski . The question is more about what version(s) of XLS files do we want to support?

This worked well for me in the past - small, easy to use (versus POI) though it only supports 2003?:
http://sourceforge.net/projects/jexcelapi/

POI supports 2007, IIRC, but is quite annoying to use from my recollection.

Another part of the challenge with XLS, from my experience, is that unless we only support a very CSV-like layout (read the first sheet only, column headers at top, no decoration, etc.), this becomes a very open-ended task. The problem with this approach is that many people don't make spreadsheets like that, so they end up having to export or reformat anyway.

My personal opinion is that export to CSV is a better option than playing the 'supported versions and formatting' game...

[ingenieroariel]

For excel I think an appropriate solution would be to explain how to
generate a good csv from an excel file in our docs and link to it in the
relevant place.

-a

On Mon, Oct 15, 2012 at 9:50 AM, Ian Schneider [email protected]:

@jj0hns0n https://github.com/jj0hns0n , agree w/ the appraisal from
@rmarianski https://github.com/rmarianski . The question is more about
what version(s) of XLS files do we want to support?

This worked well for me in the past - small, easy to use (versus POI)
though it only supports 2003?:
http://sourceforge.net/projects/jexcelapi/

POI supports 2007, IIRC, but is quite annoying to use from my recollection.

Another part of the challenge with XLS, from my experience, is that unless
we only support a very CSV-like layout (read the first sheet only, column
headers at top, no decoration, etc.), this becomes a very open-ended task.
The problem with this approach is that many people don't make spreadsheets
like that, so they end up having to export or reformat anyway.

My personal opinion is that export to CSV is a better option than playing
the 'supported versions and formatting' game...

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/145#issuecomment-9445367.

[jj0hns0n]

That does make most sense in the short term. Longer term, it dies make
sense to support actual xls, but definitely not a high priority.

On Oct 15, 2012, at 10:03, "Ariel Núñez" [email protected] wrote:

For excel I think an appropriate solution would be to explain how to
generate a good csv from an excel file in our docs and link to it in the
relevant place.

-a

On Mon, Oct 15, 2012 at 9:50 AM, Ian Schneider [email protected]:

@jj0hns0n https://github.com/jj0hns0n , agree w/ the appraisal from
@rmarianski https://github.com/rmarianski . The question is more about
what version(s) of XLS files do we want to support?

This worked well for me in the past - small, easy to use (versus POI)
though it only supports 2003?:
http://sourceforge.net/projects/jexcelapi/

POI supports 2007, IIRC, but is quite annoying to use from my
recollection.

Another part of the challenge with XLS, from my experience, is that
unless
we only support a very CSV-like layout (read the first sheet only, column
headers at top, no decoration, etc.), this becomes a very open-ended
task.
The problem with this approach is that many people don't make
spreadsheets
like that, so they end up having to export or reformat anyway.

My personal opinion is that export to CSV is a better option than playing
the 'supported versions and formatting' game...

—
Reply to this email directly or view it on GitHub<
https://github.com/GeoNode/geonode/issues/145#issuecomment-9445367>.

—
Reply to this email directly or view it on
GitHubhttps://github.com//issues/145#issuecomment-9445847.

[jj0hns0n]

CSV is working with the importer uploader backend. I will test this out and close when verified to work.

[ischneider]

Note a limitation: planetfederal/geoserver-exts#13

[simod]

In order to have the importer enabled, we need the DATASTORE in the settings (postgis database) and edit this line https://github.com/GeoNode/geonode/blob/master/geonode/settings.py#L424 to geonode.importer.
The error is "NoneType is not iterable" because https://github.com/GeoNode/geonode/blob/master/geonode/settings.py#L424 attributes is None,
The error seems to come from the importer_session creation that origins here https://github.com/GeoNode/geonode/blob/master/geonode/layers/models.py#L75

[ingenieroariel]

Includes documentation on how to use it.

[jj0hns0n]

Also see #1915