Hey all,
So I have a WFS featurecollection that has a valid WKT CRS, but no known
EPSG code. So there's no way to get a "code" out of it via
GML2EncodingUtils.epsgCode()
As a result, WFSReprojectionUtil.getDeclaredCrs() always blows up when a
WFS 1.1.0 request is made against that collection.
I applied the following patch and things started to work again. I
believe the consequence is that if you are using a "non-coded" WKT for
your featurecollection then you won't get any axis-swapping goodness out
of the WFS...but since you're using your own custom WKT CRS then I
suppose you can't really expect that.
Any other consequences that I'm missing of this change? Anyone care to
comment?
See attached patch...
--saul
(attachments)
wfsreproj.patch (620 Bytes)
Hi Saul,
The patch looks reasonable... although you better double check with
aaime, and maybe a quick comment about the rationale behind it.
Also, have you considered throwing the wkt for our crs in the
user_projections file so that it will indeed have an epsg code?
-Justin
Saul Farber wrote:
Hey all,
So I have a WFS featurecollection that has a valid WKT CRS, but no known
EPSG code. So there's no way to get a "code" out of it via
GML2EncodingUtils.epsgCode()
As a result, WFSReprojectionUtil.getDeclaredCrs() always blows up when a
WFS 1.1.0 request is made against that collection.
I applied the following patch and things started to work again. I
believe the consequence is that if you are using a "non-coded" WKT for
your featurecollection then you won't get any axis-swapping goodness out
of the WFS...but since you're using your own custom WKT CRS then I
suppose you can't really expect that.
Any other consequences that I'm missing of this change? Anyone care to
comment?
See attached patch...
--saul
!DSPAM:4007,47753a29212221849620573!
------------------------------------------------------------------------
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
!DSPAM:4007,47753a29212221849620573!
------------------------------------------------------------------------
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
!DSPAM:4007,47753a29212221849620573!
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org
Saul Farber ha scritto:
Hey all,
So I have a WFS featurecollection that has a valid WKT CRS, but no
known EPSG code. So there's no way to get a "code" out of it via GML2EncodingUtils.epsgCode()
As a result, WFSReprojectionUtil.getDeclaredCrs() always blows up
when a WFS 1.1.0 request is made against that collection.
I applied the following patch and things started to work again. I believe the consequence is that if you are using a "non-coded" WKT
for your featurecollection then you won't get any axis-swapping
goodness out of the WFS...but since you're using your own custom WKT
CRS then I suppose you can't really expect that.
I'm a little confused about what is this patch all about, in that I miss
the context. The declared CRS issue is the following:
* you have a feature type that's declared in the WFS capabilities
document. There you have to declare a native crs for it, if that's WFS
1.1, then it has to be in the urn:bla:bla:xxx form
* you're making a request that does not specify a crs, everything in
the request and in the response is, by spec, assumed to be in the
declared crs (the one you declared in the capabilities).
So, given that you can't declare a CRS in WKT form in the capabilities
(or can you?), I don't understand how your use case works?
Cheers
Andrea
Andrea,
Sorry for the lag in response. See inline:
I'm a little confused about what is this patch all about, in that I miss
the context. The declared CRS issue is the following:
* you have a feature type that's declared in the WFS capabilities
document. There you have to declare a native crs for it, if that's WFS
1.1, then it has to be in the urn:bla:bla:xxx form
I'm using FeatureTypeInfo.LEAVE with this FeatureSource, so (see line
520 in FeatureTypeInfo) the CRS in this case is the "native" CRS for
this featuresource...which happens to be an sde-defined WKT which has no
corresponding EPSG code. The datastore actually builds the CRS from a
WKT which is given to it by the DB.
* you're making a request that does not specify a crs, everything in
the request and in the response is, by spec, assumed to be in the
declared crs (the one you declared in the capabilities).
So, given that you can't declare a CRS in WKT form in the capabilities
(or can you?), I don't understand how your use case works?
You're right that you can't do this in the capabilities (or in
geoserver's UI, generally) but the source of this CRS isn't
geoserver...it's the db. I assume that if I changed from
FeatureTypeInfo.LEAVE handling to FeatureTypeInfo.REPROJECT or
FeatureTypeInfo.IGNORE handling, things would be ok.
So I guess this case is rather specific to the LEAVE setting.
With that info, does the patch make more sense? I guess the semantic of
the patch is:
"If you're using WFS 1.1.0, and you can't get a valid CRS code for your
query (probably because you're doing the "advertise one CRS, work with
another" trick involving FeatureTypeInfo.LEAVE) then just go with the
un-coded CRS that you *do* have"
Further thoughts?
--saul
Saul Farber ha scritto:
Andrea,
Sorry for the lag in response. See inline:
I'm a little confused about what is this patch all about, in that I miss
the context. The declared CRS issue is the following:
* you have a feature type that's declared in the WFS capabilities
document. There you have to declare a native crs for it, if that's WFS
1.1, then it has to be in the urn:bla:bla:xxx form
I'm using FeatureTypeInfo.LEAVE with this FeatureSource, so (see line
520 in FeatureTypeInfo) the CRS in this case is the "native" CRS for
this featuresource...which happens to be an sde-defined WKT which has no
corresponding EPSG code. The datastore actually builds the CRS from a
WKT which is given to it by the DB.
Sigh, I should have thought twice before adding the "leave" option
to the feature type reprojection possibilities. It makes sense for some
out of standard usages, but it breaks both wms and wfs standards (since
you get back data in an srs that is not the one declared, so if the
client is crs aware you're in trouble).
* you're making a request that does not specify a crs, everything in
the request and in the response is, by spec, assumed to be in the
declared crs (the one you declared in the capabilities).
So, given that you can't declare a CRS in WKT form in the capabilities
(or can you?), I don't understand how your use case works?
You're right that you can't do this in the capabilities (or in
geoserver's UI, generally) but the source of this CRS isn't
geoserver...it's the db. I assume that if I changed from
FeatureTypeInfo.LEAVE handling to FeatureTypeInfo.REPROJECT or
FeatureTypeInfo.IGNORE handling, things would be ok.
So I guess this case is rather specific to the LEAVE setting.
With that info, does the patch make more sense? I guess the semantic of
the patch is:
"If you're using WFS 1.1.0, and you can't get a valid CRS code for your
query (probably because you're doing the "advertise one CRS, work with
another" trick involving FeatureTypeInfo.LEAVE) then just go with the
un-coded CRS that you *do* have"
Hem... I guess since we already provided that option we cannot step
back now, so I'll have to apply your patch. But remember that this
is not OGC standard compliant. If you do things by the book, you
have to return data in the declared crs not matter what... the
LEAVE option is just wrong from this point of view, unfortunately
I did not think about it when I introduced it...
Cheers
Andrea
Andrea,
If it makes you feel any better, the data *IS* being served in the
correct SRS. It's just that ArcMAP is really really (really!) picky
about its WKT parsing. So when we do shapefile extracts (getFeature,
outputType=SHAPE-ZIP) the .prj file that gets into that zip file needs
to be exactly what SDE advertises and not the EPSG text of 26986.
That said, 26986 and the funky WKT that SDE returns are mathematically
equivalent.
You're right that it *could* be broken, but in our case we're very
careful to make sure that the data we serve is in the exact SRS that's
declared.
--saul
Hem... I guess since we already provided that option we cannot step
back now, so I'll have to apply your patch. But remember that this
is not OGC standard compliant. If you do things by the book, you
have to return data in the declared crs not matter what... the
LEAVE option is just wrong from this point of view, unfortunately
I did not think about it when I introduced it...
Cheers
Andrea
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel