Please :) The worldmap way probably performs better -- but it increases the amount of data duplicated between GeoServer and the GeoNode Django app which has been identified by most of the GeoNode developers as a bad thing. There are some ideas floating around about how to have GeoNode get this sort of information with just a database access while avoiding the duplication - but they are some ways off.
-- David Winslow OpenGeo - http://opengeo.org/ On Mon, Aug 22, 2011 at 12:15 PM, [email protected] < [email protected]> wrote: > Thanks David for this clarification..I tested and now the EPSG is the > correct one. > I think that this approach it's the better solution. > Should I submit a pull request? > > Ciao > L. > > 2011/8/22 David Winslow <[email protected]>: > > In mainline GeoNode we use OWSLib to get this information. Apparently > the > > coder who added this bit didn't realize that in the WMS capabilities > > document the SRS's listed are ones that the server can use for display, > not > > the native projection for the format. Looking into it, I don't think we > can > > use WMS for this at all - AFAICT there is no standard way to identify the > > native projection of a layer via WMS. (Maybe using the CRS associated > with > > the BoundingBox for the layer would do it.) > > > > Fortunately we have access to the GeoServer REST API so we can just use > {% > > layer.resource.projection %} instead. Indeed, that is what the Worldmap > > guys are copying into the Django database in the snippet you posted. > Since > > we can fix this problem without modifying the database schema I would > like > > to, modifying the schema would complicate the upgrade process a bit and > our > > documentation is lacking already. > > > > -- > > David Winslow > > OpenGeo - http://opengeo.org/ > > > > On Mon, Aug 22, 2011 at 3:26 AM, [email protected] > > <[email protected]> wrote: > >> > >> Hi Stefano, > >> > >> 2011/8/22 Stefano Menegon <[email protected]>: > >> > Hi Luca, > >> > > >> > > >> >> for every data, the Native SRS shown is always 32044. Looking at the > >> >> code it seems that the problem is in: > >> >> {% if layer.metadata.crsOptions %}<p> <strong>{% trans "Native SRS" > >> >> %}:</strong> {{ layer.metadata.crsOptions.0|default:_("No SRS > >> >> specified.") }} </p>{% endif %} > >> >> > >> >> layer.metadata.crsOptions is a big list of CRS and > >> >> layer.metadata.crsOptions.0 gives EPSG:32044. > >> >> > >> >> Any idea? > >> >> Thx > >> > > >> > I investigated it a few weeks ago. > >> > The param "layer.metadata.crsOptions" is the list of all the CRS > >> > supported by geoserver wms. > >> > So, it always displays the first of these CRS, not realy the native > SRS. > >> > > >> > You can configure the "Limited SRS list" option (Geoserver - Services > >> > - WMS) in order to change the layer.metadata.crsOptions value, > >> > however, I do not know how to get the native SRS value. > >> > > >> > //stefano menegon > >> > > >> > >> I double checked with World Map and the Layer class has got an srs > >> attribute: > >> > >> > https://github.com/cga-harvard/cga-worldmap/blob/master/src/GeoNodePy/geonode/maps/models.py#L842 > >> > >> If I am not wrong the value is set here: > >> > >> > https://github.com/cga-harvard/cga-worldmap/blob/master/src/GeoNodePy/geonode/maps/models.py#L1283 > >> > >> Then in the template you have got layer.srs > >> > >> Ciao > >> Luca > >> > >> > >> -- > >> Luca Casagrande > >> twitter: lucacasagrande > > > > > > > > -- > Luca Casagrande > twitter: lucacasagrande >
