Encoding of srsName altered when publishing with FSLoader
Just van den Broecke
I am trying to resolve compliance issues that came out of ESDIN WP12
testing, see all at:
http://code.google.com/p/inspire-foss/issues/detail?id=9
One subissue was that I changed the offline transformation to use
srsName's with the "official" encoding like:
"urn:ogc:def:crs:EPSG::4258" i.s.o. "EPSG:4258". However after loading
features into PostGIS with FSLoader the srsName's come out as
"EPSG:4258" in WFS requests. Also in the PostGIS gml_objects table
features are stored using "EPSG:4258".
This happened on deegree v3.0.2 (tools+services). Think this did not
happen in 3.0.1 but I am not sure.
best,
--Just van den Broecke
Just van den Broecke
Thanks. CRS settings were still EPSG:4258 form. So I changed in the
feature store (datastores/feature/inspire-postgis.xml):
<StorageCRS>EPSG:4258</StorageCRS>
to
<StorageCRS>urn:ogc:def:crs:EPSG::4258</StorageCRS>
Now the features are stored with urn:ogc:def:crs:EPSG::4258 OK. So far
so good.
But when testing WFS GetFeature I get strange results dependent on how I
configure CRS in services/wfs.xml
1) when using
<QueryCRS>urn:ogc:def:crs:EPSG::4326</QueryCRS>
<QueryCRS>urn:ogc:def:crs:EPSG::4258</QueryCRS>
<QueryCRS>urn:ogc:def:crs:EPSG::3034</QueryCRS>
<QueryCRS>urn:ogc:def:crs:EPSG::900913</QueryCRS>
I get
<ServiceException code="InvalidRequest">No subcontroller for request
namespace 'http://www.opengis.net/wfs' available.</ServiceException>
2) when using
<QueryCRS>EPSG:4258</QueryCRS>
<QueryCRS>EPSG:4326</QueryCRS>
<QueryCRS>EPSG:3034</QueryCRS>
<QueryCRS>EPSG:900913</QueryCRS>
I get features returned whatever is the first CRS, here as EPSG:4258,
but if EPSG:4326 is first in the above element list that CRS is returned.
I just checked in all changes:
http://code.google.com/p/inspire-foss/source/browse/#svn%2Ftrunk%2Fwebapps%2Fdeegree3
btw transforming/inserting testdata for this config is now easy when you
have an inspire_blob postgis DB with user/ps inspire/inspire configured:
1) install deegree tools (for FSLoader)
go to
http://code.google.com/p/inspire-foss/source/browse/#svn%2Ftrunk%2Ftools%2Floader%2Fdeegree-tools
and execute
./get-deegree-tools.sh
./install-deegree-tools.sh
2) transform and (FS)load test data
cd
http://code.google.com/p/inspire-foss/source/browse/#svn%2Ftrunk%2Fetl%2FNL.Kadaster%2Fbin
and execute
./testdata-etl.sh
You get a nice mix of AU,CP,GN,HY,TN features and ExMLS versions of them
(total 92 features). This what I use to test with WP12 tests for now.
The main remaining issue is "Axis ordering" (sigh).
best,
Just
Markus Schneider
Hash: SHA1
Hi,
Am 23.02.2011 11:33, schrieb Just van den Broecke:
> But when testing WFS GetFeature I get strange results dependent on how I
> configure CRS in services/wfs.xml
>
> 1) when using
> <QueryCRS>urn:ogc:def:crs:EPSG::4326</QueryCRS>
> <QueryCRS>urn:ogc:def:crs:EPSG::4258</QueryCRS>
> <QueryCRS>urn:ogc:def:crs:EPSG::3034</QueryCRS>
> <QueryCRS>urn:ogc:def:crs:EPSG::900913</QueryCRS>
> I get
>
> <ServiceException code="InvalidRequest">No subcontroller for request
> namespace 'http://www.opengis.net/wfs' available.</ServiceException>
Basically, the exception means that the WFS (which is responsible for
requests in the namespace 'http://www.opengis.net/wfs') didn't start up
successfully. If this happens, the log file (on Tomcat: catalina.out)
usually has some useful information:
...
[21:33:31] INFO: [WFSController] Initializing WFS.
[21:33:31] ERROR: [WebServicesConfiguration] Initializing WFS failed:
Invalid QuerySRS parameter: The specified CRS
'urn:ogc:def:crs:EPSG::900913' is not known.
[21:33:31] ERROR: [WebServicesConfiguration] Set the log level to TRACE
to get the stack trace.
[21:33:31] INFO: [WebServicesConfiguration]
[21:33:31] INFO: [WebServicesConfiguration] WFS startup failed.
...
The startup failed, because 'urn:ogc:def:crs:EPSG::900913' is not known.
Remove it from the config (or exchange 'urn:ogc:def:crs:EPSG::900913'
with 'EPSG:900913') and the WFS should start up fine.
The strange effect that 'EPSG:900913' is known, but
'urn:ogc:def:crs:EPSG::900913' is not should be solved for good in
deegree 3.1. See http://tracker.deegree.org/deegree-core/ticket/146
If this is a problem right now, it is also possible to add the
identifier to deegree's CRS database manually.
> 2) when using
> <QueryCRS>EPSG:4258</QueryCRS>
> <QueryCRS>EPSG:4326</QueryCRS>
> <QueryCRS>EPSG:3034</QueryCRS>
> <QueryCRS>EPSG:900913</QueryCRS>
>
> I get features returned whatever is the first CRS, here as EPSG:4258,
> but if EPSG:4326 is first in the above element list that CRS is returned.
Is this a problem? The first QueryCRS element defines the DefaultSRS (as
it is named in WFS 1.1.0). Or am I missing the point here?
> I just checked in all changes:
> http://code.google.com/p/inspire-foss/source/browse/#svn%2Ftrunk%2Fwebapps%2Fdeegree3
>
>
> btw transforming/inserting testdata for this config is now easy when you
> have an inspire_blob postgis DB with user/ps inspire/inspire configured:
>
> 1) install deegree tools (for FSLoader)
> go to
> http://code.google.com/p/inspire-foss/source/browse/#svn%2Ftrunk%2Ftools%2Floader%2Fdeegree-tools
>
> and execute
> ./get-deegree-tools.sh
> ./install-deegree-tools.sh
>
> 2) transform and (FS)load test data
> cd
> http://code.google.com/p/inspire-foss/source/browse/#svn%2Ftrunk%2Fetl%2FNL.Kadaster%2Fbin
>
> and execute
> ./testdata-etl.sh
>
> You get a nice mix of AU,CP,GN,HY,TN features and ExMLS versions of them
> (total 92 features). This what I use to test with WP12 tests for now.
Sounds cool. I will check it out for testing the relational mapping.
It's really getting close now. Short status of what works here:
- - Auto-create FeatureStore config (including complex relational mapping)
from INSPIRE schemas (currently testing with AU)
- - Auto-create PostGIS tables from config
- - Insert AU test datasets
- - Query (reconstruct) AU test datasets
Next thing is to make it possible to set this up via the service
console. Afterwards I, will post an update to the deegree lists, so
people can test it and provide feedback.
> The main remaining issue is "Axis ordering" (sigh).
I know that this is a major annoyance, but shouldn't it be enough (in
this case) to simply switch x and y in the XSL scripts?
Best regards,
Markus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk1ldKQACgkQLM5hjXxU/E4zIwCfRof0LL05QhH4rBT6AfDc59n4
ONsAoIm+ilOUfAl8BBD/rBBAOsAIq0P/
=iMrh
-----END PGP SIGNATURE-----
Just van den Broecke
See below.
Yes, this was the problem ! I now have
<QueryCRS>urn:ogc:def:crs:EPSG::4258</QueryCRS>
<QueryCRS>urn:ogc:def:crs:EPSG::4326</QueryCRS>
<QueryCRS>urn:ogc:def:crs:EPSG::3034</QueryCRS>
and this works, i.e. the WFS returns srsName's as
"urn:ogc:def:crs:EPSG::4258."
>
>> 2) when using
>> <QueryCRS>EPSG:4258</QueryCRS>
>> <QueryCRS>EPSG:4326</QueryCRS>
>> <QueryCRS>EPSG:3034</QueryCRS>
>> <QueryCRS>EPSG:900913</QueryCRS>
>>
>> I get features returned whatever is the first CRS, here as EPSG:4258,
>> but if EPSG:4326 is first in the above element list that CRS is returned.
>
> Is this a problem? The first QueryCRS element defines the DefaultSRS (as
> it is named in WFS 1.1.0). Or am I missing the point here?
The problem is that I need the "urn-format" for INSPIRE/ESDIN
compliance. According to Clemens and the WP12 ExM testsuite the
"EPSG:4258" format is non-compliant, or at least non-preferred.
>
>> I just checked in all changes:
>> http://code.google.com/p/inspire-foss/source/browse/#svn%2Ftrunk%2Fwebapps%2Fdeegree3
>>
>>
>> btw transforming/inserting testdata for this config is now easy when you
>> have an inspire_blob postgis DB with user/ps inspire/inspire configured:
>>
>> 1) install deegree tools (for FSLoader)
>> go to
>> http://code.google.com/p/inspire-foss/source/browse/#svn%2Ftrunk%2Ftools%2Floader%2Fdeegree-tools
>>
>> and execute
>> ./get-deegree-tools.sh
>> ./install-deegree-tools.sh
>>
>> 2) transform and (FS)load test data
>> cd
>> http://code.google.com/p/inspire-foss/source/browse/#svn%2Ftrunk%2Fetl%2FNL.Kadaster%2Fbin
>>
>> and execute
>> ./testdata-etl.sh
>>
>> You get a nice mix of AU,CP,GN,HY,TN features and ExMLS versions of them
>> (total 92 features). This what I use to test with WP12 tests for now.
I am getting very close to compliance with WP12 tests. DS: 19 tests 0
fails, ExM 16 tests 5 fails. What I miss in this entire exercise is
examples of how compliant INSPIRE data looks like. The XSDs are not
enough. My final issues deal with encodings of
codeLists/Spaces/localeRefs and nil values. Once my data is compliant
this could serve as example data. Probably have to check with Kadaster,
but it is just a few features per data theme.
So the above test data is still changing.
>
> Sounds cool. I will check it out for testing the relational mapping.
> It's really getting close now. Short status of what works here:
>
> - - Auto-create FeatureStore config (including complex relational mapping)
> from INSPIRE schemas (currently testing with AU)
> - - Auto-create PostGIS tables from config
> - - Insert AU test datasets
> - - Query (reconstruct) AU test datasets
>
> Next thing is to make it possible to set this up via the service
> console. Afterwards I, will post an update to the deegree lists, so
> people can test it and provide feedback.
Good to hear ! I am still curious how this works and how the DB will be
structured. Can you point me at the SVN branch perhaps and I can have look.
>
>> The main remaining issue is "Axis ordering" (sigh).
>
> I know that this is a major annoyance, but shouldn't it be enough (in
> this case) to simply switch x and y in the XSL scripts?
Yes, that is what I did using an XSL named template. See
http://code.google.com/p/inspire-foss/source/browse/trunk/etl/NL.Kadaster/xsl/gml2-to-gml3.2.1-geometry.xsl
(line 233)
So axis ordering for 4258 is now ok.
Also GDAL 1.8.0+ now supports GML3 and axis ordering but this version is
not widely available and would mean lots of rework on the current ETL
and test data.
best,
Just
Markus Schneider
Hash: SHA1
Hi Just,
Am 24.02.2011 11:56, schrieb Just van den Broecke:
>> Good to hear ! I am still curious how this works and how the DB will be
>> structured. Can you point me at the SVN branch perhaps and I can have look.
The code is in trunk. You may check out the postgis feature store module:
However, it's currently not so easy to get it running. For development,
I currently use the test cases in
src/test/java/org/deegree/feature/persistence/postgis/PostGISFeatureStoreTest.java
In order to run them, some fiddling is required (i.e. correcting paths
and providing a workspace directory).
Best regards,
Markus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk1qv0MACgkQLM5hjXxU/E6lVQCg2obDYgwN6rU7wNAzl8FgrXfN
PjsAnjpLOCXUt34/uuH7BeQResIWu9UE
=0wmC
-----END PGP SIGNATURE-----
Just van den Broecke
For my understanding: "Relational Mapping" is like the "old" way mapping
as in deegree v2 ? I think this is still very useful, also for INSPIRE,
for example with data providers that only need to provide some of the
simple Data Themes. Now that I have experience with more Data Themes, I
found that many are almost like simple features, i.e. a geometry and
some properties. e.g. CP and AU. Addresses (AD) where we started with
happened to be the most complex one.
We talked about "Hybrid" mapping as well. Was this an addition to
"Blobstore" mapping where we add extra indexing tables to deal with
(selected) WFS Filter queries? (This was one of the questions from
yesterda's presentation at Geonovum).
best,
just
Markus Schneider
Hash: SHA1
Hi Just,
Am 04.03.2011 15:29, schrieb Just van den Broecke:
> For my understanding: "Relational Mapping" is like the "old" way mapping
> as in deegree v2 ? I think this is still very useful, also for INSPIRE,
> for example with data providers that only need to provide some of the
> simple Data Themes. Now that I have experience with more Data Themes, I
> found that many are almost like simple features, i.e. a geometry and
> some properties. e.g. CP and AU. Addresses (AD) where we started with
> happened to be the most complex one.
That's right. Relational mode in deegree 3 tries to bring the mapping
possibilities of deegree 2 to deegree 3 -- and I second that it is still
relevant for many use cases. Compared to deegree 2, we target some
improvements though:
- - Configuration is based on a (simpler) custom format, not annotated
schemas
- - Support for all possibilities of GML application schemas without the
need for XSL transformations
> We talked about "Hybrid" mapping as well. Was this an addition to
> "Blobstore" mapping where we add extra indexing tables to deal with
> (selected) WFS Filter queries? (This was one of the questions from
> yesterda's presentation at Geonovum).
I guess there are two ways to look at it:
1. Improvement to BLOB-mapping to support evaluation of (certain) filter
queries directly on the backend (as you described).
2. Speed-up for complete relational mapping. In this case, a full
relational decomposition is used as the primary source of the data.
However, the gml_objects table is used to cache complete features in
order to avoid multiple SELECTs for a single feature.
Best regards,
Markus
P.S.: deegree 3.0.3 is out (not announced officially yet) and contains
some bug fixes, e.g a fix for the namespace issue reported by you [1].
[1]
http://wiki.deegree.org/deegreeWiki/deegree3/ReleaseNotes/ThreeZero#Release3.0.3
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk1yD0sACgkQLM5hjXxU/E4okgCfePC7poQNizwON1x4pLVVn2xP
dPgAn17HVTqChTYaap7xmB264pH8YBob
=rZbw
-----END PGP SIGNATURE-----