[Geoserver-users] Multiple mappings of the same type in App-Schema

GeoServer GeoServer User
1

Dear all,
reading GeoServer’s documentation, it is my understanding that it is not possible in app-schema to map the same type multiple times, from different sources, AND have all the types accessible as top level features.

At times, this may pose some challenges. For example, let’s consider a case where multiple sets of observations should be published: each set sits in its own DB table, but they should all be mapped to the om:OM_Observation type from OGC’s Observation & Measurements schema.

I can see only two possible ways to work around this limitation:

  1. Define a view in the database as the union of the source tables, and use that as sourceType in the FeatureTypeMapping
  2. Create a custom application schema and define there one specialised observation type (derived from om:OM_Observation) for each source type that needs publishing, something along the lines of:

Am I interpreting the docs correctly? Does anybody have any further suggestion?

Thanks in advance.

··· 
Best regards,
Stefano Costa

==
GeoServer Professional Services from the experts! Visit
[http://goo.gl/it488V](http://goo.gl/it488V) for more information.
==
Dott. Stefano Costa
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax:     +39 0584 1660272

[http://www.geo-solutions.it](http://www.geo-solutions.it)
[http://twitter.com/geosolutions_it](http://twitter.com/geosolutions_it)

-------------------------------------------------------
AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate.
Il loro utilizzo è consentito esclusivamente al destinatario del
messaggio, per le finalità indicate nel messaggio stesso. Qualora
riceviate questo messaggio senza esserne il destinatario, Vi preghiamo
cortesemente di darcene notizia via e-mail e di procedere alla
distruzione del messaggio stesso, cancellandolo dal Vostro sistema.
Conservare il messaggio stesso, divulgarlo anche in parte,
distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità
diverse, costituisce comportamento contrario ai principi dettati dal
D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely
for the attention and use of the named addressee(s) and may be
confidential or proprietary in nature or covered by the provisions of
privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New
Data Protection Code).Any use not in accord with its purpose, any
disclosure, reproduction, copying, distribution, or either
dissemination, either whole or partial, is strictly forbidden except
previous formal approval of the named addressee(s). If you are not the
intended recipient, please contact immediately the sender by
telephone, fax or e-mail and delete the information in this message
that has been received in error. The sender does not give any warranty
or accept liability as the content, accuracy or completeness of sent
messages and accepts no responsibility  for changes made after they
were sent or for other risks which arise as a result of e-mail
transmission, viruses, etc.
2

Stefano,

tl;dr third solution is workspace-scoped namespaces

I think you have identified the two workable solutions. The first (aggregating features) must be regarded as the correct use of WFS as designed (as explained to me in person by a voting member of the WFS committee when I complained about this problem). The second (wrapper schema) is a workaround that will reduce interoperability and works against the reason for application schemas.

WFS permits each type to be published once for each service endpoint. The idea is that all features are aggregated and a client selects the feature using a filter query. This works fine for simple features where each type has no relationships and new types are created as required. However, it is a pain in the arse when the type is a complex type that has very different structure and relationships for data from two sources; for example, laboratory assay observations on microscopic geological samples and observations on river flow level. It is ludicrous to combine them, so perhaps a wrapper schema is less bad?

There is a third solution: use another service URL. This is a great way of separating data sets while enabling WFS access. The current implementation requires a new GeoServer instance to achieve this. GeoServer supports workspace local services since GSIP 66 (November 2011), but because workspaces are still tied to namespaces, they are inadequate for app-schema types. See the discussion around GSIP 66:
<http://sourceforge.net/p/geoserver/mailman/message/28362605/&gt;
See also this user enquiry:
<http://sourceforge.net/p/geoserver/mailman/message/28774087/&gt;
See also "GSIP 66 - Workspace Local Services":
<https://github.com/geoserver/geoserver/wiki/GSIP-66---Workspace-Local-Services&gt;

If GeoServer had workspaces that each had their own service URL and own set of namespaces, you could publish each om:OM_Observation in its own workspace and your problem would be solved.

As Andrea wrote back in November 2011: "Ben, it's the model we can get funding for, so it's the model we can afford.":
<http://sourceforge.net/p/geoserver/mailman/message/28363389/&gt;

In my view, workspace-scoped namespaces would be a great improvement for app-schema.

Kind regards,
Ben.

On 12/11/15 03:07, Stefano Costa wrote:

Dear all,
reading GeoServer's documentation
<http://docs.geoserver.org/latest/en/user/data/app-schema/feature-chaining.html#multiple-mappings-of-the-same-type&gt;,
it is my understanding that it is not possible in app-schema to map the
same type multiple times, from different sources, AND have all the types
accessible as top level features.

At times, this may pose some challenges. For example, let's consider a case
where multiple sets of observations should be published: each set sits in
its own DB table, but they should all be mapped to the om:OM_Observation
type from OGC's Observation & Measurements schema
<http://schemas.opengis.net/om/2.0/observation.xsd&gt;\.

I can see only two possible ways to work around this limitation:

1. Define a view in the database as the union of the source tables, and use
that as sourceType in the FeatureTypeMapping
2. Create a custom application schema and define there one specialised
observation type (derived from om:OM_Observation) for each source type that
needs publishing, something along the lines of:

<complexType name="MyFirstObservationType">
     <complexContent>
         <extension base="om:OM_ObservationType">
             <sequence />
         </extension>
     </complexContent>
</complexType>

<element name="MyFirstObservation" type="myns:MyFirstObservationType"
substitutionGroup="om:OM_Observation" />

<complexType name="MySecondObservationType">
     <complexContent>
         <extension base="om:OM_ObservationType">
             <sequence />
         </extension>
     </complexContent>
</complexType>

<element name="MySecondObservation" type="myns:MySecondObservationType"
substitutionGroup="om:OM_Observation" />

Am I interpreting the docs correctly? Does anybody have any further
suggestion?

Thanks in advance.

------------------------------------------------------------------------------

_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
Ben Caradoc-Davies <ben@anonymised.com>
Director
Transient Software Limited <http://transient.nz/&gt;
New Zealand

3

On Wed, Nov 11, 2015 at 9:02 PM, Ben Caradoc-Davies <ben@anonymised.com>
wrote:

As Andrea wrote back in November 2011: "Ben, it's the model we can get
funding for, so it's the model we can afford.":
<http://sourceforge.net/p/geoserver/mailman/message/28363389/&gt;

Another interesting bit from that mail:
"App-schema is there, I've been told it works, but honestly I would not
consider
doing anything with it unless someone really asks for it, because it's just
too
hard to setup. GeoServer users want a GUI, give one to them and you might
start seeing more people interested in using it, and also the funds it
needs to
more forward."

Cough cough :wink: :
http://www.geo-solutions.it/blog/inspire-support-in-geoserver-made-easy-with-hale/

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V 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

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

-------------------------------------------------------

4

On 12/11/15 20:31, Andrea Aime wrote:

Cough cough :wink: :
http://www.geo-solutions.it/blog/inspire-support-in-geoserver-made-easy-with-hale/

And I also saw this tweeted or retweeted a few days ago by a certain @geowolf :slight_smile:
http://blog.dhpanel.eu/2015/11/02/geoserver-app-schema-integration-hale-2-9-4-is-out/

<borat>Niiice!</borat>

--
Ben Caradoc-Davies <ben@anonymised.com>
Director
Transient Software Limited <http://transient.nz/&gt;
New Zealand