GeoNode / geonode

GeoNode is an open source platform that facilitates the creation, sharing, and collaborative use of geospatial data.
https://geonode.org/
Other
1.43k stars 1.12k forks source link

Upload fails with .prj but says projection was not defined #880

Closed ingenieroariel closed 11 years ago

ingenieroariel commented 11 years ago

Added a zipped file with the sample data (please remove the .gif extension) and an screenshot

screen shot 2013-05-24 at 3 07 12 pm

https://f.cloud.github.com/assets/54999/562559/cedb1274-c4ad-11e2-98bc-74641c101570.gif

mbertrand commented 11 years ago

@ingenieroariel, When I try to load this shapefile in QGIS it opens the Coordinate Reference System Selector dialog - so QGIS can't seem to figure out the projection either. Maybe it's a bad/mismatched prj file? Seems to be a few "unknowns" inside it:

GEOGCS["GCS_unnamed ellipse",DATUM["D_unknown",SPHEROID["Unknown",6378137,0]]

capooti commented 11 years ago

both QGIS and PostGIS/GeoServer use GDAL, so I think it is an invalid project file, maybe generated with some software not using GDAL. Can you attach a zip of this dataset here?

mbertrand commented 11 years ago

@capooti, here it is, replace .gif with .zip after downloading: https://f.cloud.github.com/assets/54999/562559/cedb1274-c4ad-11e2-98bc-74641c101570.gif

capooti commented 11 years ago

On my box both QGIS and GDAL (1.10) recognize the .prj without problems. Thinking about it well, I think GeoServer it is using an internal PROJ.4 version to detect the spatial reference. I have tried to manually create the Shapefile Store in GS: when I try to publish Nativer SRS is detected as UNKNOWN, and Declared SRS is missing, therefore trying to publish it fails. Declaring a WGS84 seems working.

So far, I think you have two options (I did not test both of them):

  1. use another prj file, with a WGS84 declaration
  2. try adding a custom projection in GeoServer, with the prj declaration: http://docs.geoserver.org/stable/en/user/advanced/crshandling/customcrs.html you could use this definition: http://spatialreference.org/ref/sr-org/google-projection/html/ This way GeoServer should recognize the .prj file

In any case I think it makes sense that GeoNode raises that error, and the error message seems to me adequate. A possible improvement for GeoNode > 2.0 could be to let the user to declare the EPSG when uploading if .prj is missing or incorrectly read.

ingenieroariel commented 11 years ago

Thanks for this debugging info guys. If I am not mistaken, this dataset in particular is part of the Natural Earth vector dataset, the one recommended for OSGeo LiveDVD examples.

Am I correct to assume that this file is EPSG:900913 (or similar) instead of WGS84?

On Wed, Jun 5, 2013 at 4:03 AM, Paolo Corti notifications@github.comwrote:

On my box both QGIS and GDAL (1.10) recognize the .prj without problems. Thinking about it well, I think GeoServer it is using an internal PROJ.4 version to detect the spatial reference. I have tried to manually create the Shapefile Store in GS: when I try to publish Nativer SRS is detected as UNKNOWN, and Declared SRS is missing, therefore trying to publish it fails. Declaring a WGS84 seems working.

So far, I think you have two options (I did not test both of them):

  1. use another prj file, with a WGS84 declaration
  2. try adding a custom projection in GeoServer, with the prj declaration: http://docs.geoserver.org/stable/en/user/advanced/crshandling/customcrs.html you could use this definition: http://spatialreference.org/ref/sr-org/google-projection/html/ This way GeoServer should recognize the .prj file

In any case I think it makes sense that GeoNode raises that error, and the error message seems to me adequate. A possible improvement for GeoNode > 2.0 could be to let the user to declare the EPSG when uploading if .prj is missing or incorrectly read.

— Reply to this email directly or view it on GitHubhttps://github.com/GeoNode/geonode/issues/880#issuecomment-18963528 .

capooti commented 11 years ago

Yes, according to this: http://lists.osgeo.org/pipermail/gdal-dev/2011-September/030284.html So, rather thant messing up the GeoServer EPSG database I think using an EPSG:900913 will be the way to go. cheers

ingenieroariel commented 11 years ago

Okay, I am closing this as it is specific to that dataset. If it becomes more serious than this, please reopen.