[Geoserver-devel] Request for small code change

GeoServer GeoServer Developer
1

Hi, we are writing geoserver extensions and trying to hide the concept of a namespace from client code.

The code that emits the coverage id in DescribeCoverage responses for WCS 1.0 and 2.0 was extensible, and we were able to implement the behavior we need.

However, for WCS 1.1, the fact that a namespace is prepended to a coverage id with a colon delimeter is hardcoded here:
project: org.geoserver.gs-wcs1_1
org.geoserver.wcs.response.DescribeCoverageTransformer.java

protected void handleCoverageDescription(CoverageInfo ci) throws Exception {
start(“wcs:CoverageDescription”);
element(“ows:Title”, ci.getTitle());
element(“ows:Abstract”, ci.getDescription());
handleKeywords(ci.getKeywords());
element(“wcs:Identifier”, ci.getStore().getWorkspace().getName() + “:” + ci.getName());
handleMetadataLinks(ci.getMetadataLinks(), “simple”);
handleDomain(ci);
handleRange(ci);
handleSupportedCRSs(ci);
handleSupportedFormats(ci);
end(“wcs:CoverageDescription”);
}

Could this line be changed to delegate returning the prefixed coverage id to the CoverageInfo object? i.e.

element(“wcs:Identifier”, ci.prefixedName());

That way I could implement the behavior I need in my own CoverageInfo object.

Thanks,
Scott

This e-mail and any files transmitted with it may be proprietary and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of Exelis Inc. The recipient should check this e-mail and any attachments for the presence of viruses. Exelis Inc. accepts no liability for any damage caused by any virus transmitted by this e-mail.

2

Are you trying to hide namespace, prefix or workspace?

If you turn off the global WCS and use the per workspace virtual service you should get what you need. Or look into how default workspace works.

As for the change open up a big ticket / pull request and be sure to include a test case :slight_smile:

On Sat, Feb 21, 2015 at 12:24 PM Ellis, Scott - Exelis <Scott.Ellis@anonymised.com…4132…> wrote:

Hi, we are writing geoserver extensions and trying to hide the concept of a namespace from client code.

The code that emits the coverage id in DescribeCoverage responses for WCS 1.0 and 2.0 was extensible, and we were able to implement the behavior we need.

However, for WCS 1.1, the fact that a namespace is prepended to a coverage id with a colon delimeter is hardcoded here:
project: org.geoserver.gs-wcs1_1
org.geoserver.wcs.response.DescribeCoverageTransformer.java

protected void handleCoverageDescription(CoverageInfo ci) throws Exception {
start(“wcs:CoverageDescription”);
element(“ows:Title”, ci.getTitle());
element(“ows:Abstract”, ci.getDescription());
handleKeywords(ci.getKeywords());
element(“wcs:Identifier”, ci.getStore().getWorkspace().getName() + “:” + ci.getName());
handleMetadataLinks(ci.getMetadataLinks(), “simple”);
handleDomain(ci);
handleRange(ci);
handleSupportedCRSs(ci);
handleSupportedFormats(ci);
end(“wcs:CoverageDescription”);
}

Could this line be changed to delegate returning the prefixed coverage id to the CoverageInfo object? i.e.

element(“wcs:Identifier”, ci.prefixedName());

That way I could implement the behavior I need in my own CoverageInfo object.

Thanks,
Scott

This e-mail and any files transmitted with it may be proprietary and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of Exelis Inc. The recipient should check this e-mail and any attachments for the presence of viruses. Exelis Inc. accepts no liability for any damage caused by any virus transmitted by this e-mail.

Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@anonymised.comsourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

3

Hi Jody, thanks for those ideas but they will not work for our case. Our extension actually allows GeoServer to provide OWS interfaces for a dynamic backing coverage store of our own design, containing many coverages that are not actually published to GeoServer at all, only discovered at runtime. There is no concept of a namespace, workspace, or prefix in our backing coverage store, only a coverage id.

For 1.0 DescribeCoverage responses, it was a simple matter of overriding ResourceInfo.getPrefixedName().

For 2.0, it was just a matter of implementing the WCS20DescribeCoverageExtension interface.

But for 1.1, because of how the DescribeCoverageTransformer is coded, we can’t get our desired behavior.

It seems that the 1.1 DescribeCoverageTransformer implementation does not provide the proper encapsulation of behavior for how the coverage id is written out in the response. I think my proposed code change would remedy that by making the CoverageInfo object responsible for returning how the coverage id should come out in the response (in our case, without a prefix).

Thanks,
Scott

From: Jody Garnett [jody.garnett@anonymised.com.]
Sent: Saturday, February 21, 2015 1:45 PM
To: Ellis, Scott - Exelis; geoserver-devel@lists.sourceforge.net
Subject: Re: [Geoserver-devel] Request for small code change

Are you trying to hide namespace, prefix or workspace?

If you turn off the global WCS and use the per workspace virtual service you should get what you need. Or look into how default workspace works.

As for the change open up a big ticket / pull request and be sure to include a test case :slight_smile:

On Sat, Feb 21, 2015 at 12:24 PM Ellis, Scott - Exelis <Scott.Ellis@anonymised.com> wrote:

Hi, we are writing geoserver extensions and trying to hide the concept of a namespace from client code.

The code that emits the coverage id in DescribeCoverage responses for WCS 1.0 and 2.0 was extensible, and we were able to implement the behavior we need.

However, for WCS 1.1, the fact that a namespace is prepended to a coverage id with a colon delimeter is hardcoded here:
project: org.geoserver.gs-wcs1_1
org.geoserver.wcs.response.DescribeCoverageTransformer.java

protected void handleCoverageDescription(CoverageInfo ci) throws Exception {
start(“wcs:CoverageDescription”);
element(“ows:Title”, ci.getTitle());
element(“ows:Abstract”, ci.getDescription());
handleKeywords(ci.getKeywords());
element(“wcs:Identifier”, ci.getStore().getWorkspace().getName() + “:” + ci.getName());
handleMetadataLinks(ci.getMetadataLinks(), “simple”);
handleDomain(ci);
handleRange(ci);
handleSupportedCRSs(ci);
handleSupportedFormats(ci);
end(“wcs:CoverageDescription”);
}

Could this line be changed to delegate returning the prefixed coverage id to the CoverageInfo object? i.e.

element(“wcs:Identifier”, ci.prefixedName());

That way I could implement the behavior I need in my own CoverageInfo object.

Thanks,
Scott

This e-mail and any files transmitted with it may be proprietary and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of Exelis Inc. The recipient should check this e-mail and any attachments for the presence of viruses. Exelis Inc. accepts no liability for any damage caused by any virus transmitted by this e-mail.

Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@anonymised.comsourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

4

On Sat, Feb 21, 2015 at 9:22 PM, Ellis, Scott - Exelis <
Scott.Ellis@anonymised.com> wrote:

Hi, we are writing geoserver extensions and trying to hide the concept
of a namespace from client code.

The code that emits the coverage id in DescribeCoverage responses for WCS
1.0 and 2.0 was extensible, and we were able to implement the behavior we
need.

However, for WCS 1.1, the fact that a namespace is prepended to a coverage
id with a colon delimeter is hardcoded here:
project: org.geoserver.gs-wcs1_1
org.geoserver.wcs.response.DescribeCoverageTransformer.java

        protected void handleCoverageDescription(CoverageInfo ci) throws
Exception {
            start("wcs:CoverageDescription");
            element("ows:Title", ci.getTitle());
            element("ows:Abstract", ci.getDescription());
            handleKeywords(ci.getKeywords());
           * element("wcs:Identifier",
ci.getStore().getWorkspace().getName() + ":" + ci.getName());*
            handleMetadataLinks(ci.getMetadataLinks(), "simple");
            handleDomain(ci);
            handleRange(ci);
            handleSupportedCRSs(ci);
            handleSupportedFormats(ci);
            end("wcs:CoverageDescription");
        }

Could this line be changed to delegate returning the prefixed coverage id
to the CoverageInfo object? i.e.

           * element("wcs:Identifier", ci.prefixedName());*

That way I could implement the behavior I need in my own CoverageInfo
object.

I don't mind the change, but you'll have to make a pull request. And I
suggest you think hard about how to add tests to lock down
this behavior, because a vanilla GeoServer does not really need it.
With many people contributing pull requests to GeoServer you basically
have only two types of behaviors, those that have tests failing
when you change them, and those that get broken, it's just a matter of
time...

Cheers
Andrea

--

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

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