On Fri, Oct 21, 2011 at 4:05 PM, Gabriel Roldan <[email protected]> wrote:
> On Fri, Oct 21, 2011 at 4:57 AM, Andrea Aime
> <[email protected]> wrote:
> > On Fri, Oct 21, 2011 at 1:12 AM, Gabriel Roldan <[email protected]>
> wrote:
> >> And to add to Andrea's comment, you might want to try using the WFS
> >> 1.1 client instead (by setting version=1.1.0 instead of 1.0.0 in the
> >> getcapabilities URL)
> >
> > If you do pay attention to axis flipping, the WFS 1.1 client does not
> behave
> > like normal stores and returns the data in lat/lon order:
> >
> > http://jira.codehaus.org/browse/GEOT-2300
>
> I'm not totally sure if this is what you mean, but this is how I think
> is behaves:
> The WFS 1.1 datastore builds up the FeatureType CRS from the
> capabilities. The capabilities document declares a DfaultSRS of
> urn:x-ogc:def:crs:EPSG:4326 (and if I got it correctly we have the
> convention that only EPSG:XXX forces x/y - lon/lat). That is lat/lon,
> and a GetFeature request to the backend WFS _will_ return lat/lon.
> So in that case, IMHO, the problem is not that the WFS 1.1 DataStore
> does not perform any magic, it is sticking to the spec and what the
> EPSG database declares to be the axis order of the CRS.
>
> What I did find is that GeoServer does not work properly out of the
> box with a datastore that declares a native CRS with lat/lon axis
> order. And this is because the FeatureType configuration uses only
> EPSG:XXX to store the native SRS, regardless of storing the native CRS
> WKT properly, when it comes to set the declared CRS it presents both
> native and declared as EPSG:4326, hence getting confused about axis
> ordering.
>
> The only way I got to properly cascade a 4326 feature type (eg.
> topp:states) is by setting the SRS handling policy to "reproject
> native to declared", regardless of both native and declared showing
> EPSG:4326.
>
> So it is my opinion that the GeoServer config and CRS handling should
> be "extended" in order to being able of properly handling datastores
> with native lat/lon CRS's.
> I started a private branch to experiment on this a while back but had
> no time to keep up. The idea would be that both EPSG:XXX and urn
> styles are allowed in the config, and that the CRS lookup presents
> both options for each CRS that's natively in y/x - lat/lon axis order.
>
> Does that make sense?
>
It does, I just think all stores should report data back in the natural x/y
order,
so I would fix the store instead of GeoServer, but it's just me, I like it
simple
instead of flexible.
Cheers
Andrea
--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
-------------------------------------------------------
------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________
Geotools-gt2-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
