Dear all,
I am trying to set up geoserver as a gazetteer according to the INSPIRE data specification on geographical names. The geographical names are in a postgresql/postgis database and I am using the app-schema plugin and feature chaining to configure the feature type.
If I don’t set app-schema.joining = true, it works fine but it needs a long time to complete a request. If I set app-schema.joining = true, it doesn’t work because all ‘chained’ features are nested within the first feature instead of being nested within the correct one. That is:
– app-schema.joining = false
<snm:NamedPlace gml:id=“namedplace.5802”>
snm:name
snm:GeographicalName…</snm:GeographicalName>
</snm:name>
</snm:NamedPlace>
<snm:NamedPlace gml:id=“namedplace.5802”>
snm:name
snm:GeographicalName…</snm:GeographicalName>
</snm:name>
</snm:NamedPlace>
[5000 snm:NamedPlace follow]
– app-schema.joining = true
<snm:NamedPlace gml:id=“namedplace.5802”>
snm:name
snm:GeographicalName…</snm:GeographicalName>
</snm:name>
[5000 snm:name follow]
</snm:NamedPlace>
<snm:NamedPlace gml:id=“namedplace.5802”>
[no snm:name on the second and the following features]
</snm:NamedPlace>
[5000 snm:NamedPlace follow]
You can see the non-working feature here (it needs a long time because it produces a huge and wrong gml file):
http://eiel.lbd.org.es/ideac/wfs?request=GetFeature&typename=snm:NamedPlace
Any ideas? I can send the configuration file, if you want. I do not know whether it is polite or allowed on this list.
Best regards,
Miguel
Miguel,
are any of your tables denormalised? With joining, tables/views should be normalised:
http://docs.geoserver.org/latest/en/user/data/app-schema/joining.html#database-design-guidelines
Handling of multivalued properties is detailed here (Rini, our expert on this topic, is back on Monday):
http://docs.geoserver.org/latest/en/user/data/app-schema/feature-chaining.html
If you still have problems, please reply attaching your mapping files for the affected types.
Kind regards,
Ben.
On 02/04/13 22:09, Miguel R. Luaces wrote:
Dear all,
I am trying to set up geoserver as a gazetteer according to the INSPIRE
data specification on geographical names. The geographical names are in
a postgresql/postgis database and I am using the app-schema plugin and
feature chaining to configure the feature type.
If I don't set app-schema.joining = true, it works fine but it needs a
long time to complete a request. If I set app-schema.joining = true, it
doesn't work because all 'chained' features are nested within the first
feature instead of being nested within the correct one. That is:
-- app-schema.joining = false
<snm:NamedPlace gml:id="namedplace.5802">
<snm:name>
<snm:GeographicalName>...</snm:GeographicalName>
</snm:name>
</snm:NamedPlace>
<snm:NamedPlace gml:id="namedplace.5802">
<snm:name>
<snm:GeographicalName>...</snm:GeographicalName>
</snm:name>
</snm:NamedPlace>
[5000 snm:NamedPlace follow]
-- app-schema.joining = true
<snm:NamedPlace gml:id="namedplace.5802">
<snm:name>
<snm:GeographicalName>...</snm:GeographicalName>
</snm:name>
[5000 snm:name follow]
</snm:NamedPlace>
<snm:NamedPlace gml:id="namedplace.5802">
[no snm:name on the second and the following features]
</snm:NamedPlace>
[5000 snm:NamedPlace follow]
You can see the non-working feature here (it needs a long time because
it produces a huge and wrong gml file):
http://eiel.lbd.org.es/ideac/wfs?request=GetFeature&typename=snm:NamedPlace
<http://eiel.lbd.org.es/ideac/wfs?request=GetFeature&typename=snm:NamedPlace>
Any ideas? I can send the configuration file, if you want. I do not know
whether it is polite or allowed on this list.
Best regards,
Miguel
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
Ben,
thank you very much for your answer.
are any of your tables denormalised?
No. They are all normalised. I attach the SQl that creates the tables. There are four tables. The main one is namedplace, which has a one to many relationship with gegraphicalname, which in turn has two one to many relationships with spellingofname and pronunciationof name. There are primary keys and foreign keys on all the relationships.
Handling of multivalued properties is detailed here (Rini, our expert on this topic, is back on Monday):
I followed the documentation. Without app-schema.joining = true, everything works fine (but slow). With app-schema.joining = true all features are nested with the first result. I attach the feature type definition.
Best regards,
Miguel
table_structure.sql (3.34 KB)
snm_NamedPlace.xml (10.5 KB)
Hi Miguel,
This sounds like a bug introduced in 2.2 release.
If you’re using 2.2.x, please use 2.3 instead and see if it fixes the problem.
Cheers
Rini
From: Miguel R. Luaces [mailto:luaces@anonymised.com]
Sent: Wednesday, 3 April 2013 2:14 PM
To: Caradoc-Davies, Ben (CESRE, Kensington)
Cc: geoserver-users@lists.sourceforge.net; Angreani, Rini (CESRE, Kensington)
Subject: Re: [Geoserver-users] App-schema not working with joining=true
Ben,
thank you very much for your answer.
are any of your tables denormalised?
No. They are all normalised. I attach the SQl that creates the tables. There are four tables. The main one is namedplace, which has a one to many relationship with gegraphicalname, which in turn has two one to many relationships with spellingofname and pronunciationof name. There are primary keys and foreign keys on all the relationships.
Handling of multivalued properties is detailed here (Rini, our expert on this topic, is back on Monday):
I followed the documentation. Without app-schema.joining = true, everything works fine (but slow). With app-schema.joining = true all features are nested with the first result. I attach the feature type definition.
Best regards,
Miguel
Hi,
If you’re using 2.2.x, please use 2.3 instead and see if it fixes the
problem.
I am using geoserver 2.3.
Best regards,
Miguel
Dear all,
just to close the subject, I have decided to stop using Geoserver and
start using deegree because the implementation of a WFS serving
complex features is way much easy.
In a quick comparison, Geoserver is much easier to use because it has
a really nice user interface to configure the server. On the other
hand, deegree is really hard to configure because you have to tamper
with xml configuration files. But, deegree seems to be much more
suitable for my task because it has native working support for complex
features.
Best regards,
Miguel
On Wed, Apr 10, 2013 at 10:58 AM, Miguel R. Luaces <luaces@anonymised.com>wrote:
Dear all,
just to close the subject, I have decided to stop using Geoserver and
start using deegree because the implementation of a WFS serving
complex features is way much easy.
In a quick comparison, Geoserver is much easier to use because it has
a really nice user interface to configure the server. On the other
hand, deegree is really hard to configure because you have to tamper
with xml configuration files. But, deegree seems to be much more
suitable for my task because it has native working support for complex
features.
Out of curiosity, what store are you using in deegree?
The one that stores the XML as a blob in the database, plus some extra
attributes
as direct columns of the db, or one that works like app-schema, mapping
table
joins and columns to attributes in the xml schema?
If it's the latter, what makes it easier to use in deegree compared to the
app-schema
configuration?
Cheers
Andrea
--
GeoServer training in Milan, 6th & 7th June 2013! Visit
http://geoserver.geo-solutions.it for more information.
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
Hi,
Out of curiosity, what store are you using in deegree?
one that works like app-schema, mapping
table
joins and columns to attributes in the xml schema?
This one.
If it's the latter, what makes it easier to use in deegree compared to the
app-schema
configuration?
First, I could not make the geoserver plugin work against a database
with joining=true. Without joining=true it was so painfully slow that
it was unusable.
Second, it has a wizard to generate the configuration and the database
tables starting from an XML Schema. It is not perfect, and it requires
a little knowledge of the XML Schema that you are mapping, but I
created a working INSPIRE-compliant WFS based on the Geographical
Names data specification in two hours. Using geoserver, I needed four
days to do the same.
The problems with deegree: the documentation is poor, and the
configuration is ugly (tampering with XML files). I would never
recommend deegree to a final user.
Best regards,
Miguel
On 10/04/13 17:42, Miguel R. Luaces wrote:
Second, it has a wizard to generate the configuration and the database
tables starting from an XML Schema.
Miguel, do you have an existing database schema, and if so, how do you map it to the generated deegree database schema?
Kind regards,
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
Dear Ben,
do you have an existing database schema,
Yes.
how do you map
it to the generated deegree database schema?
I first used the deegree wizard to generate the database schema. Then,
I changed the deegree configuration file to use my database schema
instead of the generated one. So I do not map database schemas, I use
the deegree wizard to generate a configuration file and then I change
it to adapt it to my database schema.
Best regards,
Miguel
Hi Miguel,
I was able to recreate the same problem reported earlier
(http://jira.codehaus.org/browse/GEOS-5618).
The problem in the JIRA issue was because of getID() not being handled
properly with joining. The bug wasn't detected because all the joining unit
tests aren't using getID() anymore, but I don't remember why I did that (it
was causing problems at that time).
I noticed you're not using idExpression in your types. Try adding
idExpression in your mapping files and map them to your primary keys
directly (not using getId()).
If this doesn't work, you can send me some of your sample database dump
(privately if you prefer) so I can debug this and investigate.
I will schedule the bug to be fixed next iteration.
Cheers
Rini
--
View this message in context: http://osgeo-org.1560.x6.nabble.com/App-schema-not-working-with-joining-true-tp5044084p5046958.html
Sent from the GeoServer - User mailing list archive at Nabble.com.