GeoServer trunk does not correctly match a shapefile's projection to the correct epsg

I think I discussed this with Mike already. The thing is, the referencing module in gt2 assumes if two datums have different names, they are different, so that will never match.

Hmmm... i guess I don't understand what part is the datum name. It seems they are both named "WGS_1984". Or does the name of the spheroid have to match as well? I see in this case they are indeed different, "WGS_84" vs "WGS 84".

Hummm... right. In fact I wrote a little synthetic program and the prj contents are recognized as EPSG:4326:

import org.geotools.referencing.CRS;
import org.opengis.referencing.crs.CoordinateReferenceSystem;


public class Compare {
    public static void main(String[] args) throws Exception {
        System.setProperty("org.geotools.referencing.forceXY", "true");
        String wkt = "GEOGCS[\"GCS_WGS_1984\",\n" + 
        		"DATUM[\"WGS_1984\",\n" + 
        		"SPHEROID[\"WGS_1984\",6378137,298.257223563]],\n" + 
        		"PRIMEM[\"Greenwich\",0],\n" + 
        		"UNIT[\"Degree\",0.017453292519943295]]";
        CoordinateReferenceSystem prj = CRS.parseWKT(wkt);
        System.out.println(prj);
        System.out.println(CRS.lookupIdentifier(prj, true));
    }
}

Running the above results in EPSG:4326, and quickly, so it's not even doing a full scan.
I'll have to check with a shapefile tomorrow.

So I was reaching the wrong conclusions. The lookup was fast, but only because the deep lookup does first and indexed search, and only after falls back on a sequential scan.
But the code is found only if we allow the UI to make a deep scan of the EPSG registry. If we do that we'll end up with people waiting for various seconds (5-7) if the search falls back on the sequential scan (which happens always if the match cannot be found, and it's not so unlikely).
So:

• is it ok to make the user wait? (maybe, we do have the ajax feedback image spinning on the right top, so the user is informed that GeoServer is doing something)
• alteratively, we could add a "deep search" button in the layer UI so that the user initiates a full scan manually if the quick one did not succeed

Opinions? I'd say, let's go for option one.

Btw, was this happening from the UI or by using the REST configuration extensions?

Ivan confirms he was using the RESTConfig extension. The same question applies: is it ok for a network configuration call to span various seconds, or do we want to add some parameters to it to force extensive SRS lookups?

I prefer to make them wait. I don't really like exposing internal implementation details through api unless it is absolutely necessary. Especially for an api whose aim is to have the user be able to do as little work as possible to get data configured. So my answer to people who complain about the call taking too long would be to update the .prj file

Hmmm.. this would be a 180 on the change implemented for http://jira.codehaus.org/browse/GEOS-3167 which split out the expensive portions.
The srs lookup we can somehow control, it should never be more than, say, 20 seconds on a slow machine?
The "compute the native bbox part" we cannot, it may take hours if you have something like the hundredth of millions records or more (terabyte datasets are not science fiction anymore).
So... shall we call manually the full srs lookup in both the rest api and the UI (and leave the catalog builder as is) or just revert the work done in GEOS-3167?

Well when I ported the rest config extension to trunk i manually updated calls to catalog builder to include the expensive ones. But I assume I missed this case. As for the UI... not sure, i have not touched it much recently so I delegate to others on that.

Soo... i am not sure exactly what the problem here is... uploading the file works for me... it renders ok, just its native srs does not get an epsg code, which is quite common no?

This is apparently fixed now... i think it is related to some of the other recent rest fixes. Closing.

Hi, I've a similar case :

Geoserver didn't recognized this SRS

GEOGCS["GCS_WGS_1984",
DATUM["D_WGS_1984",
SPHEROID["WGS_1984", 6378137.0, 298.257223563]],
PRIMEM["Greenwich", 0.0],
UNIT["degree", 0.017453292519943295],
AXIS["Longitude", EAST],
AXIS["Latitude", NORTH]]

Same here on 2.1.3, uploading via restconfig, with:

GEOGCS["GCS_WGS_1984",
DATUM["D_WGS_1984",
SPHEROID["WGS_1984",6378137,298.257223563]],
PRIMEM["Greenwich",0],
UNIT["Degree",0.017453292519943295]]

which matches http://spatialreference.org/ref/epsg/4326/