[Geoserver-devel] Extending app-schema to allow several mappings for the same target element in different stores

Hi,

Sorry for the cross posting but this subject touches GeoServer and GeoTools.

I'm just thinking loud here about how app-schema could be extended to allow several mappings for the same target element in different sores.

Right now with app-schema is not possible to create more that one mapping per target element in the global application, even in different stores.

I can see three main reasons for this:

     - is not possible to have several workspaces with the same name space
     - the layer name (feature type name) needs to be the same as the target element and unique globally
     - the lookup for the feature chaining is made globally (i.e. all the data stores are used)

Assuming that we manage to allow several workspaces to use the same name space (I need to investigate this).

It should be possible to allow the same target element to be mapped in different stores. To make this happen it should be possible to have a layer with a name different from the mapped target element and the global logic implemented in the data access registry needs also to be updated to search first in the store and after globally:
https://github.com/geotools/geotools/blob/master/modules/extension/app-schema/app-schema/src/main/java/org/geotools/data/complex/DataAccessRegistry.java

Thoughts about this ? Is there any other reason from those above to limit one mapping per target element ?

Regards,

Nuno Oliveira

--

GeoServer Professional Services from the experts!
Visit http://goo.gl/it488V for more information.

Nuno Miguel Carvalho Oliveira
@nmcoliveira
Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 333 8128928

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.

Nuno,

I think you have covered the main reasons. I have a question: how would you access these mappings from a WFS service endpoint? WFS only allows each feature type to be published once for each service endpoint. Workspace-local service endpoints that were not tied to a particular namespace would be most useful. There was some discussion about the problems for app-schema of the one-to-one relationship between workspaces and namespaces when GSIP-66 workspace-local services were introduced:
https://sourceforge.net/p/geoserver/mailman/message/28362605/
https://sourceforge.net/p/geoserver/mailman/message/28362664/
https://github.com/geoserver/geoserver/wiki/GSIP%2066%20-%20Workspace%20Local%20Services

Kind regards,
Ben.

On 03/02/17 12:58, Nuno Oliveira wrote:

Hi,

Sorry for the cross posting but this subject touches GeoServer and GeoTools.

I'm just thinking loud here about how app-schema could be extended to
allow several mappings for the same target element in different sores.

Right now with app-schema is not possible to create more that one
mapping per target element in the global application, even in different
stores.

I can see three main reasons for this:

     - is not possible to have several workspaces with the same name space
     - the layer name (feature type name) needs to be the same as the
target element and unique globally
     - the lookup for the feature chaining is made globally (i.e. all
the data stores are used)

Assuming that we manage to allow several workspaces to use the same name
space (I need to investigate this).

It should be possible to allow the same target element to be mapped in
different stores. To make this happen it should be possible to have a
layer with a name different from the mapped target element and the
global logic implemented in the data access registry needs also to be
updated to search first in the store and after globally:
https://github.com/geotools/geotools/blob/master/modules/extension/app-schema/app-schema/src/main/java/org/geotools/data/complex/DataAccessRegistry.java

Thoughts about this ? Is there any other reason from those above to
limit one mapping per target element ?

Regards,

Nuno Oliveira

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

Hi Ben,

Sorry for the late come back.
I'm still thinking about this when I have something more concrete I will share.

Regards,

Nuno Oliveira

On 02/03/2017 02:44 AM, Ben Caradoc-Davies wrote:

Nuno,

I think you have covered the main reasons. I have a question: how would you access these mappings from a WFS service endpoint? WFS only allows each feature type to be published once for each service endpoint. Workspace-local service endpoints that were not tied to a particular namespace would be most useful. There was some discussion about the problems for app-schema of the one-to-one relationship between workspaces and namespaces when GSIP-66 workspace-local services were introduced:
https://sourceforge.net/p/geoserver/mailman/message/28362605/
https://sourceforge.net/p/geoserver/mailman/message/28362664/
https://github.com/geoserver/geoserver/wiki/GSIP%2066%20-%20Workspace%20Local%20Services

Kind regards,
Ben.

On 03/02/17 12:58, Nuno Oliveira wrote:

Hi,

Sorry for the cross posting but this subject touches GeoServer and GeoTools.

I'm just thinking loud here about how app-schema could be extended to
allow several mappings for the same target element in different sores.

Right now with app-schema is not possible to create more that one
mapping per target element in the global application, even in different
stores.

I can see three main reasons for this:

     - is not possible to have several workspaces with the same name space
     - the layer name (feature type name) needs to be the same as the
target element and unique globally
     - the lookup for the feature chaining is made globally (i.e. all
the data stores are used)

Assuming that we manage to allow several workspaces to use the same name
space (I need to investigate this).

It should be possible to allow the same target element to be mapped in
different stores. To make this happen it should be possible to have a
layer with a name different from the mapped target element and the
global logic implemented in the data access registry needs also to be
updated to search first in the store and after globally:
https://github.com/geotools/geotools/blob/master/modules/extension/app-schema/app-schema/src/main/java/org/geotools/data/complex/DataAccessRegistry.java

Thoughts about this ? Is there any other reason from those above to
limit one mapping per target element ?

Regards,

Nuno Oliveira

--

GeoServer Professional Services from the experts!
Visit http://goo.gl/it488V for more information.

Nuno Miguel Carvalho Oliveira
@nmcoliveira
Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 333 8128928

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.