Deegree 3 WFS: referring to INSPIRE schemas
Frans
I have succeeded in setting up a WFS for IGNB, serving seven feature
types from the AU and HY themes. The data were transformed to
SpatialDataSets and then loaded into PostgreSQL using the feature
loader. The base URL for the service is http://research.geodan.nl/deegree3_IGNB/services.
I will post more information in another thread when it is working
completely.
I do have a remaining problem: The DescribeFeatureType request does
not work well and because of that I can not validate the GetFeature
output. I see that the INSPIRE XSD files are contained in the Deegree3
web app. That is nice, it means they will always be available as long
as the service is running. But it is the way these schemas are
referred to that is causing problems. When I issue a general
DescribeFeatureType request I get a document that contains file links
that can not be used on other machines. It seems the document is
generated by the WFS. It seems the place where the reference to the
schemas is configured is WEB-INF\workspace\datasources\feature\inspire-
postgis.xml. Is that the only place?
In the GetFeature output the schema is not referenced with a file, but
it uses a URL that can't be used either because we use a reverse proxy
to transform the host name/port. The schema reference in the
GetFeature URL uses a URL that is inaccessible on the Internet. So in
my case I would want to configure the host name to be used for schema
references somewhere, I guess..
I have published the INSPIRE schemas on a separate web server too
(http://research.geodan.nl/esdin/schemas/v3.0). Maybe it is easier to
just refer to these? But how can I configure this? I have tried using
the GMLSchemaFileURL setting in inspire_postgis.xml, but that did not
work (both DescribeFeatureType and GetFeature fail with unspecified
errors).
Can anyone help me with this?
Just van den Broecke
Googd to see this progress. I can't help you with the Schema
configuration, it is more a deegree-specific issue.
best,
Just
--
kind regards / met vriendelijke groet,
--Just
Just van den Broecke ju...@justobjects.nl
Just Objects B.V. tel +31 65 4268627 Skype: justb4
The Netherlands http://www.justobjects.nl
Markus Schneider
Am 19.10.2010 12:06, schrieb Frans:
> I have succeeded in setting up a WFS for IGNB, serving seven feature
> types from the AU and HY themes. The data were transformed to
> SpatialDataSets and then loaded into PostgreSQL using the feature
> loader. The base URL for the service is http://research.geodan.nl/deegree3_IGNB/services.
> I will post more information in another thread when it is working
> completely.
>
> I do have a remaining problem: The DescribeFeatureType request does
> not work well and because of that I can not validate the GetFeature
> output. I see that the INSPIRE XSD files are contained in the Deegree3
> web app. That is nice, it means they will always be available as long
> as the service is running. But it is the way these schemas are
> referred to that is causing problems. When I issue a general
> DescribeFeatureType request I get a document that contains file links
> that can not be used on other machines.
Without a customized configuration, you should not see file links, but
links that point back
to the resources servlet!? Did you do any customizations in wfs.xml /
postgis.xml?
Links in your DescribeFeatureType response should look like this:
http://[...]/resources/datasources/feature/schemas/inspire/annex1/AdministrativeUnits.xsd
> It seems the document is
> generated by the WFS. It seems the place where the reference to the
> schemas is configured is WEB-INF\workspace\datasources\feature\inspire-
> postgis.xml. Is that the only place?
Yes. Unless you changed the Format settings in wfs.xml (don't do it).
> In the GetFeature output the schema is not referenced with a file, but
> it uses a URL that can't be used either because we use a reverse proxy
> to transform the host name/port. The schema reference in the
> GetFeature URL uses a URL that is inaccessible on the Internet. So in
> my case I would want to configure the host name to be used for schema
> references somewhere, I guess..
The reverse proxy setup is causing problems already in your
GetCapabilities response. Your service currently
reports DCPs like this:
...
<ows:Operation name="GetFeature">
<ows:DCP>
<ows:HTTP>
<ows:Get xlink:href="http://tm-sr:8080/deegree3_IGNB/console/../services?"></ows:Get>
<ows:Post xlink:href="http://tm-sr:8080/deegree3_IGNB/console/../services"></ows:Post>
</ows:HTTP>
</ows:DCP>
</ows:Operation>
...
Clients will actually use the report these URLs. Fixing this problem should take care of the DescribeFeatureType problem as well.
The best solution would be to configure the reverse proxy to pipe through the original request URL (I don't know if this is possible).
If this doesn't work, try to hard-code the GET and POST URLs in workspace/services/main.xml. Should look something like
this (please validate against the configuration schema):
...
<DCP>
<HttpGet>http://http://research.geodan.nl/deegree3_IGNB/services?</HttpGet>
<HttpPost>http://http://research.geodan.nl/deegree3_IGNB/services</HttpPost>
</DCP>
Afterwards, the WFS should report the configured URLs instead the request URL. Can you verify that?
Additionally (after removing your customized schema location settings in wfs.xml), the GetFeature/DescribeFeatureType responses
should contain resolvable references as well.
Best regards,
Markus
Frans Knibbe
Thanks for your reply. I will try to respond point by point:
1) I haven't touched wfs.xml. The only file I changed was
inspire_blob.xml. I tried changing inspire-postgis.xml but that did
not improve matters.
2) Without any further customization, when I issue a general
DescribeFeatureType request I get a collection of <import> elements in
which the schemaLocation attributes use file links (example:
http://bit.ly/cdMdUn). I notice that if I do specify a feature type I
get the same response.
3) Thanks for pointing me to workspace/services/main.xml. That was
exactly what I was looking for! Unfortunately, changing the file did
not have any noticeable effect (after restarting the web app). Maybe I
should build a new version of Deegree3? The one I am using is a couple
of weeks old now..
Regards,
Frans
On Oct 19, 10:14 pm, Markus Schneider <mar...@beefcafe.de> wrote:
> Hi Frans,
>
> Am 19.10.2010 12:06, schrieb Frans:> I have succeeded in setting up a WFS for IGNB, serving seven feature
> > types from the AU and HY themes. The data were transformed to
> > SpatialDataSets and then loaded into PostgreSQL using the feature
Just van den Broecke
> Hello Markus,
>
(omitted)
> 3) Thanks for pointing me to workspace/services/main.xml. That was
> exactly what I was looking for! Unfortunately, changing the file did
> not have any noticeable effect (after restarting the web app). Maybe I
> should build a new version of Deegree3? The one I am using is a couple
> of weeks old now..
Maven deps to 3.0-pre9 (build@20101018-1758 by hudson)
I don't know/think it solves your problem.
I take it you use the deegree3 webapp ?
best,
Just
Frans Knibbe
Frans Knibbe
main.xml seems to be ignored.
Markus Schneider
I tried it on my machine and found that it also reports "file:/" URLs in
the DescribeFeatureType response.
I also figured out a workaround (a real fix should become available with
3.0-rc1 next week).
1. Move/copy the schemas folder from src/main/webapp/WEB-INF to
src/main/webapp/WEB-INF/workspace/datasources/feature.
2. Adapt inspire-postgis.xml to use schemas/inspire/annex1/ instead of
../../../schemas/inspire/annex1/.
Afterwards, my DescribeFeatureType response uses http-URLs instead of
file-URLs.
I also observed that the DCP-settings in
src/main/webapp/WEB-INF/workspace/services/main.xml work fine afterwards
(both in GetCapabilities responses and in DescribeFeatureType responses).
This way, one should be able to fix problems with reverse proxy setups.
Here's the main.xml I used:
<deegreeServiceController xmlns="http://www.deegree.org/webservices"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
configVersion="0.6.0"
xsi:schemaLocation="http://www.deegree.org/webservices
http://schemas.deegree.org/webservices/0.6.0/services.xsd">
<DCP>
<!--
Only provide the URLs below, if you need to hard-wire the URLs
returned in GetCapabilities responses (e.g. for
proxy-setups). By default, the services use the URL that has been
used to sent the request which works fine in
most cases and requires no configuration.
-->
<HTTPGet>http://10.19.1.224:8080/deegree3/services?</HTTPGet>
<HTTPPost>http://10.19.1.224:8080/deegree3/services</HTTPPost>
<SOAP>http://10.19.1.224:8080/deegree3/services</SOAP>
</DCP>
</deegreeServiceController>
@Frans: Could you check if this fixes the problem for you?
Best regards,
Markus
Frans Knibbe
Thanks a lot for investigating and solving the problem! I can now
confirm that the solution works. It did take a lot of attempts to get
it working. At first I only noticed the file links being replaced, but
the DCP setting still seemed to be ignored. Then after some more
tampering I got the DCP settings to work, but I lost the JDBC
connection (Error performing query: No suitable driver found). But
after a few more attempts and frequently restarting tomcat (just
restarting the web app seemed to be less thorough) it is all working
now.
By the way: Tomcat does report the Deegree 3 app not closing properly
when it is stopped, running a severe risk of memory leaks occuring. I
assume that won't happen with the stable release, but if you were
unaware of this you might want to look at it.
Regards,
Frans
On 22 okt, 13:10, "Markus Schneider" <mar...@beefcafe.de> wrote:
> Hi all,
>
> I tried it on my machine and found that it also reports "file:/" URLs in
> the DescribeFeatureType response.
>
> I also figured out a workaround (a real fix should become available with
> 3.0-rc1 next week).
>
> 1. Move/copy the schemas folder from src/main/webapp/WEB-INF to
> src/main/webapp/WEB-INF/workspace/datasources/feature.
> 2. Adapt inspire-postgis.xml to use schemas/inspire/annex1/ instead of
> ../../../schemas/inspire/annex1/.
>
> Afterwards, my DescribeFeatureType response uses http-URLs instead of
> file-URLs.
>
> I also observed that the DCP-settings in
> src/main/webapp/WEB-INF/workspace/services/main.xml work fine afterwards
> (both in GetCapabilities responses and in DescribeFeatureType responses).
> This way, one should be able to fix problems with reverse proxy setups.
> Here's the main.xml I used:
>
> <deegreeServiceController xmlns="http://www.deegree.org/webservices"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> configVersion="0.6.0"
> <!--
> Only provide the URLs below, if you need to hard-wire the URLs
> returned in GetCapabilities responses (e.g. for
> proxy-setups). By default, the services use the URL that has been
> used to sent the request which works fine in
> most cases and requires no configuration.
> -->
> <HTTPGet>http://10.19.1.224:8080/deegree3/services?</HTTPGet>
> <HTTPPost>http://10.19.1.224:8080/deegree3/services</HTTPPost>
> <SOAP>http://10.19.1.224:8080/deegree3/services</SOAP>
> </DCP>
> </deegreeServiceController>
>
> @Frans: Could you check if this fixes the problem for you?
>
> Best regards,
> Markus
>
>
>
>
>
>
>
> > I have tried 3.0-pre9 now, but still no effect. The <DCP> setting in
> > main.xml seems to be ignored.
>
Andreas Schmitz
Hi,
> By the way: Tomcat does report the Deegree 3 app not closing properly
> when it is stopped, running a severe risk of memory leaks occuring. I
> assume that won't happen with the stable release, but if you were
> unaware of this you might want to look at it.
funny you should say that. Half an hour ago I fixed these problems (at
least the ones I could reproduce) ;-) The fixes will be included in the
next pre-release (probably rc1).
Best regards, Andreas
--
l a t / l o n GmbH
Aennchenstrasse 19 53177 Bonn, Germany
phone ++49 +228 18496-0 fax ++49 +228 18496-29
http://www.lat-lon.de http://www.deegree.org
* * * * * * * * * * * * * * * * * * * * * * * * * * * *
deegree day 2010
http://deegreeday.deegree.org
* * * * * * * * * * * * * * * * * * * * * * * * * * * *
Markus Schneider
> the DCP setting still seemed to be ignored. Then after some more
> tampering I got the DCP settings to work, but I lost the JDBC
> connection (Error performing query: No suitable driver found). But
> after a few more attempts and frequently restarting tomcat (just
> restarting the web app seemed to be less thorough) it is all working
> now.
Yes, the PostGIS driver problem is still unsolved. I've realized the
following circumstances to cause it:
- Restarting deegree 3 with configured PostGIS feature store
- Having multiple webapps in the same Tomcat that all rely on PostGIS
(e.g. deegre 2 + deegree 3)
I also observed that it usually helps to restart Tomcat. Does anybody know
how to fix this problem correctly?
Best regards,
Markus
Just van den Broecke
> Yes, the PostGIS driver problem is still unsolved. I've realized the
> following circumstances to cause it:
>
> - Restarting deegree 3 with configured PostGIS feature store
> - Having multiple webapps in the same Tomcat that all rely on PostGIS
> (e.g. deegre 2 + deegree 3)
>
> I also observed that it usually helps to restart Tomcat. Does anybody know
> how to fix this problem correctly?
of webapp inits seemed to matter. I get this error during webapp startup
but from then on the deegree3 webapp/postgres driver works ok. I have a
Tomcat6 with several PostGIS clients like GeoServer, GeoNetwork. I think
I tried different versions of Postgres/gis JDBC drivers (to have them
all using the same) but never got it fixed. It works but with the error.
best,
Just