Re: [Geoserver-users] Multi-parameter NetCDF values in 2.10.x

[kweis...@harris.com]

Upon closer look I believe the ticket that introduced my error is GEOT-5392.  
Lots of changes under that ticket, but the addition in GranuleDescriptor L356 
which calls gcReader.getOriginalEnvelope()
Seems to be culprit.  When called without a coverageName NetCDFReader dips into 
the checkUnspecifiedCoverage method with the "UN$PECIFIED" coverage name which 
will throw an IllegalArgumentException if the gridCoverageCount > 1.

As best as I can tell, this is a bug and would prevent any multi-coverage 
netcdf files from being used within an ImageMosaic.  Unless anyone has an idea 
of how to work around this issue I'll submit a ticket to the GeoTools jira.

Thanks,

Kevin M. Weiss
Software Engineer
CRITICAL NETWORKS / HARRIS CORPORATION
harris.com  / kevin.we...@harris.com


-Original Message-----
From: kweis...@harris.com [mailto:kweis...@harris.com] 
Sent: Wednesday, January 04, 2017 8:57 AM
To: geoserver-users@lists.sourceforge.net 

Subject: [Geoserver-users] Multi-parameter NetCDF values in 2.10.x

Hello again list,
I noticed an issue with our NetCDF ImageMosaic coverages after upgrading from 
2.9.0 to 2.10.0  The issue only seems to affect multi-parameter netcdf source 
files and seems to fail silently unless in verbose logging mode.  After the 
upgrade, any data stored in a netCDF with multiple parameters returned zeros 
for any data request.  WMS requests resulted in a black box spanning the 
dataset and WCS responses were valid containers, but all zeroed data.  When I 
switch to verbose logging I see a DEBUG statement that contains a stacktrace 
with the following: 

DEBUG [imagemosaic.catalog] - Skipping invalid granule
java.lang.IllegalArgumentException: Need to specify the coverageName for a 
reader related to multiple coverages
at 
org.geotools.coverage.io.netcdf.NetCDFReader.checkUnspecifiedCoverage(NetCDFReader.java:732)
at 
org.geotools.coverage.io.netcdf.NetCDFReader.getOriginalEnvelope(NetCDFReader.java:753)
at 
org.geotools.coverage.io.netcdf.NetCDFReader.getOriginalEnvelope(NetCDFReader.java:748)
at 
org.geotools.gce.imagemosaic.GranuleDescriptor.init(GranuleDescriptor.java:365)
.

I see that some work was done under GEOT-5518 to add support for multiple bands 
in NetCDF coverages and I suspect these are related.  Is there a way to update 
existing layers to handle the new multiple bands support without redeploying 
everything?  Perhaps a modification to the coverage.xml or properties file for 
the affected coverages?

For clarity, my netcdf file contains the following parameters CAT_GPML(time, z, 
y, x) lat(y, x) lon(y, x)

We don't expose the lat & lon parameters as they are only provided as a cross 
check for the projection handling (and unfortunately we don't control the 
source).

Thanks,

Kevin M. Weiss
Software Engineer
CRITICAL NETWORKS / HARRIS CORPORATION
harris.com  / kevin.we...@harris.com


--
Check out the vibrant tech community on one of the world's most engaging tech 
sites, SlashDot.org! http://sdm.link/slashdot 
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

[Geoserver-users] Multi-parameter NetCDF values in 2.10.x

[kweis...@harris.com]

Hello again list,
I noticed an issue with our NetCDF ImageMosaic coverages after upgrading from 
2.9.0 to 2.10.0  The issue only seems to affect multi-parameter netcdf source 
files and seems to fail silently unless in verbose logging mode.  After the 
upgrade, any data stored in a netCDF with multiple parameters returned zeros 
for any data request.  WMS requests resulted in a black box spanning the 
dataset and WCS responses were valid containers, but all zeroed data.  When I 
switch to verbose logging I see a DEBUG statement that contains a stacktrace 
with the following: 

DEBUG [imagemosaic.catalog] - Skipping invalid granule
java.lang.IllegalArgumentException: Need to specify the coverageName for a 
reader related to multiple coverages
at 
org.geotools.coverage.io.netcdf.NetCDFReader.checkUnspecifiedCoverage(NetCDFReader.java:732)
at 
org.geotools.coverage.io.netcdf.NetCDFReader.getOriginalEnvelope(NetCDFReader.java:753)
at 
org.geotools.coverage.io.netcdf.NetCDFReader.getOriginalEnvelope(NetCDFReader.java:748)
at 
org.geotools.gce.imagemosaic.GranuleDescriptor.init(GranuleDescriptor.java:365)
.

I see that some work was done under GEOT-5518 to add support for multiple bands 
in NetCDF coverages and I suspect these are related.  Is there a way to update 
existing layers to handle the new multiple bands support without redeploying 
everything?  Perhaps a modification to the coverage.xml or properties file for 
the affected coverages?

For clarity, my netcdf file contains the following parameters
CAT_GPML(time, z, y, x)
lat(y, x)
lon(y, x)

We don't expose the lat & lon parameters as they are only provided as a cross 
check for the projection handling (and unfortunately we don't control the 
source).

Thanks,

Kevin M. Weiss
Software Engineer
CRITICAL NETWORKS / HARRIS CORPORATION
harris.com  / kevin.we...@harris.com


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] App-schema troubleshooting

[kweis...@harris.com]

A little further down the rabbit hole I think I see the issue, but I'm still 
not sure how to resolve it.  Per the wxxm schema (add link) a 
wxxm:DiscreteCoverage is just an extension of gml:DiscreteCoverage.  It doesn't 
add any elements, it just extends.  wxxm:domainSet defines itself as a 
substitution for gml:domainSet which exists under the gml:DiscreteCoverage.  

During the XML encoding GMLEncodingUtils.java inspects the schema and creates a 
list of acceptable propertyNames (namespace & element name) that could be 
present on the element.  In my case, gml:domainSet is returned as a potential 
propertyName.  The problem is that in the next step (GMLEncodingUtils.java 
L222) it tries to retrieve the properties from the feature hashmap by 
propertyName, but gml:domainSet isn't present in the map, only wxxm:domainSet 
so the match is not found and that section of the XML is not populated.  

The curious part is that the gml:domainSet attribute contains a 
substitutionGroup List which does in fact contain a wxxm:domainSet 
XSDElementDeclaration.  Unfortunately, I don't see any code that inspects the 
substitutionGroup.  A simple change such as iterating over the 
substitutionGroups and calling feature.getProperties(subGroupPropertyName) in 
the event that the first getProperties(propertyName) returns an empty 
collection might work, but could add significant processing time for complex 
schemas.

Does anyone have any other ideas or suggestions?

Thanks,

Kevin M. Weiss
Software Engineer
CRITICAL NETWORKS / HARRIS CORPORATION
harris.com  / kevin.we...@harris.com


-Original Message-
From: kweis...@harris.com [mailto:kweis...@harris.com] 
Sent: Monday, December 12, 2016 4:25 PM
To: Ben Caradoc-Davies 
Cc: geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] App-schema troubleshooting

Hey Ben,
I tried your mapping suggestion, but the output remained the same.  I even 
downloaded and generated a mapping file via HALE (which is pretty cool btw), 
but the same problem occurs.  Stepping through the debugger I noticed that when 
the BindingPropertyExtractor.java tries to load the properties for the 
wxxm:DiscreteCoverage type, it finds a gml:domainSet element, but not the 
wxxm:domainSet element which specifies the substitutionGroup="gml:domainSet".  
Is there a trick to get app-schema to recognize substituionGroups as valid 
replacements?

Thanks,

Kevin M. Weiss
Software Engineer
CRITICAL NETWORKS / HARRIS CORPORATION
harris.com  / kevin.we...@harris.com

-Original Message-
From: Ben Caradoc-Davies [mailto:b...@transient.nz]
Sent: Thursday, December 08, 2016 10:04 PM
To: Weiss, Kevin 
Cc: Nuno Oliveira ; 
geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] App-schema troubleshooting

Kevin,

I think this is a feature chaining problem. The first thing I noticed is that 
in discretecoverage.xml you have 
discretecoverage_domain but I think this should 
match the targetElement of the nested type (wxxm:DomainObject). I also saw 
inputAttribute which might work but I think is meant for wrapping a 
non-application-schema data access (I have never used this and had to look it 
up). Can you just use OCQL as in the feature chaining guide? I threw in an 
isMultiple for good measure, giving me:


wxxm:domainSet

id
wxxm:DomainObject
FEATURE_LINK

true
true


Kind regards,
Ben.
--
Check out the vibrant tech community on one of the world's most engaging tech 
sites, SlashDot.org! http://sdm.link/slashdot 
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] App-schema troubleshooting

[kweis...@harris.com]

Hey Ben,
I tried your mapping suggestion, but the output remained the same.  I even 
downloaded and generated a mapping file via HALE (which is pretty cool btw), 
but the same problem occurs.  Stepping through the debugger I noticed that when 
the BindingPropertyExtractor.java tries to load the properties for the 
wxxm:DiscreteCoverage type, it finds a gml:domainSet element, but not the 
wxxm:domainSet element which specifies the substitutionGroup="gml:domainSet".  
Is there a trick to get app-schema to recognize substituionGroups as valid 
replacements?

Thanks,

Kevin M. Weiss
Software Engineer
CRITICAL NETWORKS / HARRIS CORPORATION
harris.com  / kevin.we...@harris.com

-Original Message-
From: Ben Caradoc-Davies [mailto:b...@transient.nz] 
Sent: Thursday, December 08, 2016 10:04 PM
To: Weiss, Kevin 
Cc: Nuno Oliveira ; 
geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] App-schema troubleshooting

Kevin,

I think this is a feature chaining problem. The first thing I noticed is that 
in discretecoverage.xml you have 
discretecoverage_domain but I think this should 
match the targetElement of the nested type (wxxm:DomainObject). I also saw 
inputAttribute which might work but I think is meant for wrapping a 
non-application-schema data access (I have never used this and had to look it 
up). Can you just use OCQL as in the feature chaining guide? I threw in an 
isMultiple for good measure, giving me:


wxxm:domainSet

id
wxxm:DomainObject
FEATURE_LINK

true
true


Kind regards,
Ben.
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] App-schema troubleshooting

[kweis...@harris.com]

Thanks Ben,

I'll have to check out HALE.  Automatic mapping files sounds nice!

Unfortunately, I haven't had a chance to step through the debugger yet as I've 
been away from the office and don't have direct access to my dev system.  That 
is my next step though.

I've attached both my mapping files for the discrete coverage.  You'll see a 
few commented out blocks in each of stuff I've tried that hasn't worked.  
Thanks for taking a look.

I don't see any warn logs regarding wxxm:DomainSetType.  It seems to create & 
register the attribute successfully.

Kevin M. Weiss
Software Engineer
CRITICAL NETWORKS / HARRIS CORPORATION
harris.com  / kevin.we...@harris.com


-Original Message-
From: Ben Caradoc-Davies [mailto:b...@transient.nz] 
Sent: Thursday, December 08, 2016 5:25 PM
To: Weiss, Kevin 
Cc: Nuno Oliveira ; 
geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] App-schema troubleshooting

On 09/12/16 10:24, kweis...@harris.com wrote:
> I figured the debugger was the way to go, but hoped there was an 
> easier way. :P

Kevin, I feel your pain. The debugger is an end-user-interface antipattern.

One interesting user interface option is HALE, which I have heard of but not 
used. HALE has app-schema support. It might be useful to see what app-schema 
mapping HALE generates for the problematic element:
http://www.geo-solutions.it/blog/inspire-support-in-geoserver-made-easy-with-hale/
http://hale.igd.fraunhofer.de/2.9.4/help/topic/eu.esdihumboldt.hale.doc.appschema/html/introduction/intro.html

> I'll take a look at the recommended breakpoints and see if I can figure out 
> what's happening.  The element I'm trying to encode is a 
> wxxm:DiscreteCoverage which should have a wxxm:domainSet element with 0-N 
> wxxm:DomainObject within.  DiscreteCoverage displays fine as does any gml 
> prefixed elements within it, but the wxxm:domainSet refuses to encode (along 
> with any of its children).  I've tried specifying the complexType via 
> targetAttributeNode as I've had that issue before, but it hasn't made a 
> difference here.
> The wxxm schema is available here (http://www.wxxm.aero/schema/2.0/wxxm.xsd) 
> with the objects in question present in the adjacent coverage.xsd file.

Can we please see your mapping for this element, and the targetAttributeNode 
mapping you tried? It is possible that for some reason the type substitution 
search fails to detect the target type as valid for this element. Are there any 
warnings in the logs about this mapping?

Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited <http://transient.nz/> New Zealand



http://www.geotools.org/app-schema";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://www.geotools.org/app-schema AppSchemaDataAccess.xsd">

  
 wxxm
 http://www.wxxm.aero/wxxm/2.0
  
  
 gml
 http://www.opengis.net/gml/3.2
  
  
 xlink
 http://www.w3.org/1999/xlink
  

   
   discretecoverage_domain.xml 
   

  

wxxm_discretecoverage

  
  
dbtype
postgisng
  
  
jndiReferenceName
java:comp/env/jdbc/postgres
  

   Expose primary keys
   true

 
  



../wxxm/wxxm.xsd





discretecoverage

wxxm_discretecoverage

discretecoverage

wxxm:DiscreteCoverage
false





   wxxm:DiscreteCoverage
   wxxm:DiscreteCoverageType
   
  uuid
   






	
		wxxm:domainSet
		wxxm:DomainSetType
		true

		id
discretecoverage_domain
FEATURE_LINK



	
		gml:rangeSet/gml:ValueArray
   
  strConcat(uuid,'-valueArrayId')
   
	
	
		gml:rangeSet/gml:ValueArray/gml:valueComponents/wxxm:Amount
		
 	   uom
   amount_uom

		
 	   xlink:href
   amount_href


amount
	
	
	
		gml:coverageFunction/gml:CoverageMappingRule/gml:ruleDefinition

rule
	
	

	
		gml:identifier
		
 	   codeSpace
   'urn:ietf:rfc:1738'

   
  'http://www.wxxm.aero/feature/contour'
   
	

Re: [Geoserver-users] App-schema troubleshooting

[kweis...@harris.com]

I figured the debugger was the way to go, but hoped there was an easier way. :P

I'll take a look at the recommended breakpoints and see if I can figure out 
what's happening.  The element I'm trying to encode is a wxxm:DiscreteCoverage 
which should have a wxxm:domainSet element with 0-N wxxm:DomainObject within.  
DiscreteCoverage displays fine as does any gml prefixed elements within it, but 
the wxxm:domainSet refuses to encode (along with any of its children).  I've 
tried specifying the complexType via targetAttributeNode as I've had that issue 
before, but it hasn't made a difference here.

The wxxm schema is available here (http://www.wxxm.aero/schema/2.0/wxxm.xsd) 
with the objects in question present in the adjacent coverage.xsd file.

Thanks for the assistance,

Kevin M. Weiss
Software Engineer
CRITICAL NETWORKS / HARRIS CORPORATION
harris.com  / kevin.we...@harris.com

-Original Message-
From: Ben Caradoc-Davies [mailto:b...@transient.nz] 
Sent: Thursday, December 08, 2016 12:03 PM
To: Nuno Oliveira ; Weiss, Kevin 

Cc: geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] App-schema troubleshooting

Yes, the debugger is my tool of choice as well. Another important breakpoint is 
gt-app-schema DataAccessMappingFeatureIterator.computeNext, where you can see 
features being built and check their content:
https://github.com/geotools/geotools/blob/master/modules/extension/app-schema/app-schema/src/main/java/org/geotools/data/complex/DataAccessMappingFeatureIterator.java#L968

Other things to try before the debugger include targetAttributeNode if your 
types are too general, although app-schema is now quite good at searching 
substitution groups.

Kevin, what elements are missing and what is their type?

Kind regards,
Ben.

On 09/12/16 05:03, Nuno Oliveira wrote:
> Hello,
>
> I have the same issue and unfortunately I didn't find any nice way to 
> troubleshot this kind of problems too.
> So if someone knows a better way to do this kind of trouble shooting I 
> would love to hear it too.
>
> So far I rely on debugging to understand what I "did wrong" with my 
> mappings.
> I typically put a debug point around this lines and check if the 
> complex entity as all the expected info:
> https://github.com/geotools/geotools/blob/master/modules/extension/xsd
> /xsd-core/src/main/java/org/geotools/xml/Encoder.java#L759-L775
>
> In my case when I don't get the data encoded this typically means that 
> the Encoder doesn't like my XML schema and refuses to encode the data.
> So try to paste the excerpt of your schema that is not encoded here 
> with some context (the schema and the mappings) and maybe someone will 
> give you some feedback (I will try).
>
> Regards,
>
> Nuno Oliveira
>
> On 12/08/2016 02:52 PM, kweis...@harris.com wrote:
>> Hello again everyone,
>> I'm working on creating some app-schema mapping files for some complex 
>> schemas and have been having a few issues.  Specifically, I've got some 
>> elements that for some reason refuse to populate.  I don't get any errors 
>> during boot up nor when a request is processed, the element is just omitted 
>> in the final output.  With verbose logging enabled it appears that the data 
>> is loaded.  A TRACE log message [org.geotools.data.complex.filter] displays 
>> when a request is made and does contain the element (and sub-elements) in 
>> question.
>>
>> I'm curious if there's any additional troubleshooting I can perform to 
>> figure out this issue.
>>
>> GeoServer: 2.10.0
>> Tomcat: 8.0.33
>>
>> Thanks,
>>
>> Kevin M. Weiss
>> Software Engineer
>> CRITICAL NETWORKS / HARRIS CORPORATION harris.com  / 
>> kevin.we...@harris.com
>>
>>
>>
>> -
>> - Developer Access Program for Intel Xeon Phi Processors 
>> Access to Intel Xeon Phi processor-based developer platforms.
>> With one year of Intel Parallel Studio XE.
>> Training and support from Colfax.
>> Order your platform today.http://sdm.link/xeonphi 
>> ___
>> Geoserver-users mailing list
>> Geoserver-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>>
>

--
Ben Caradoc-Davies 
Director
Transient Software Limited <http://transient.nz/> New Zealand

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

[Geoserver-users] App-schema troubleshooting

[kweis...@harris.com]

Hello again everyone,
I'm working on creating some app-schema mapping files for some complex schemas 
and have been having a few issues.  Specifically, I've got some elements that 
for some reason refuse to populate.  I don't get any errors during boot up nor 
when a request is processed, the element is just omitted in the final output.  
With verbose logging enabled it appears that the data is loaded.  A TRACE log 
message [org.geotools.data.complex.filter] displays when a request is made and 
does contain the element (and sub-elements) in question.

I'm curious if there's any additional troubleshooting I can perform to figure 
out this issue.

GeoServer: 2.10.0
Tomcat: 8.0.33

Thanks,

Kevin M. Weiss
Software Engineer
CRITICAL NETWORKS / HARRIS CORPORATION
harris.com  / kevin.we...@harris.com



--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] app-schema and multi line segments

[kweis...@harris.com]

Ben,
It appears that the simple feature encodes the data as a MultiCurve.  Our 
schema currently doesn't allow MultiCurve, but I can inquire about a 
modification.  While I don't think there is anything syntactically wrong with 
encoding multiple LineStringSegments within a gml:Curve, perhaps a 
gml:MultiCurve is a better choice to indicate the potential multiplicity in 
this instance.

Thanks for the help.

Kevin M. Weiss
Software Engineer
CRITICAL NETWORKS / HARRIS CORPORATION
harris.com  / kevin.we...@harris.com



-Original Message-
From: Ben Caradoc-Davies [mailto:b...@transient.nz] 
Sent: Monday, December 05, 2016 5:40 PM
To: Weiss, Kevin ; geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] app-schema and multi line segments

Kevin,

app-schema should use the same infrastructure as simple features for encoding 
geometries. To test whether this is an app-schema problem, please try 
publishing the source table as a simple feature and making a WFS 2.0.0 request 
to see how the geometry is encoded.

I have not used Curve geometry types but others on this list have.

Kind regards,
Ben.


On 06/12/16 08:36, kweis...@harris.com wrote:
> Hello all,
> Has anyone had luck getting app-schema to encode a geometry with multiple 
> segments?  I'm trying to map a single geometry entry in the DB to a gml:Curve 
> with multiple LineStringSegments, but instead of multiple segments the 
> app-schema appears to be concatenating them into a single segment with no 
> breaks.  I have tried persisting the geometry as both MultiLineString and 
> GeometryCollection(LineString, LineString) using PostGIS 2.2.2, but both 
> experience the same incorrect output translation.  For example, this is the 
> output I'm expecting:
>
>   http://www.opengis.net/gml/srs/epsg.xml#4052"; srsDimension="2" 
> axisLabels="latitude longitude">
>   
> 
>   42.1062 -82.4293 42.0936 
> -82.4319 42.0803 -82.4344 42.0809 -82.4349 42.0670 -82.4381 42.0415 -82.4498 
> 42.0297 -82.4560
> 
> 
>   42.3323 -82.4765 42.3232 
> -82.4714 42.3113 -82.4643 42.3071 -82.4622 42.2936 -82.4569 42.2657 -82.4473 
> 42.2515 -82.4431 42.2431 -82.4404 42.2301 -82.4359 42.2179 -82.4331 42.2044 
> -82.4317 42.1921 -82.4300
> 
>   
> 
>
> However, this is output from app-schema:
>
>srsName="http://www.opengis.net/gml/srs/epsg.xml#4052";>
> 
>   
>   
> 42.1062 -82.4293 42.0936 -82.4319 42.0803 -82.4344 42.0809 -82.4349 42.067 
> -82.4381 42.0415 -82.4498 42.0297 -82.456 42.3323 -82.4765 42.3232 -82.4714 
> 42.3113 -82.4643 42.3071 -82.4622 42.2936 -82.4569 42.2657 -82.4473 42.2515 
> -82.4431 42.2431 -82.4404 42.2301 -82.4359 42.2179 -82.4331 42.2044 -82.4317 
> 42.1921 -82.43
>   
>   
> 
>   
>
> As you can see the two geometries are joined in a contiguous fashion which is 
> undesirable.
>
> If anyone has any ideas on how to achieve the desired result I would greatly 
> appreciate it.
>
> Thanks,
>
> Kevin M. Weiss
> Software Engineer
> CRITICAL NETWORKS / HARRIS CORPORATION harris.com  / 
> kevin.we...@harris.com
>
>
>
> --
>  ___
> Geoserver-users mailing list
> Geoserver-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>

--
Ben Caradoc-Davies 
Director
Transient Software Limited <http://transient.nz/> New Zealand

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] GeoServer Slow to Start with Lots of Namespaces ( > 3h )

[kweis...@harris.com]

I haven’t tested this in a while, but we experienced this problem in the past 
and discovered that using the JDBC-Config plugin (from community modules) 
resolved the issue.  There is an initial hit during the first run with 
JDBC-Config enabled as it reads every resource file, validates it, and then 
inserts into the database, but then on subsequent startups the system is ready 
almost instantaneously.  

Kevin M. Weiss
Software Engineer
CRITICAL NETWORKS / HARRIS CORPORATION
harris.com  / kevin.we...@harris.com


From: Jaroslav Urik [mailto:jarda.u...@gmail.com] 
Sent: Thursday, December 01, 2016 8:30 AM
To: Julian Hollingbery ; 
geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] GeoServer Slow to Start with Lots of Namespaces 
( > 3h )

Yes, that might solve it, but I do not know how to achieve this.. Also I hope 
that geonetwork just check if file exist and does not read the whole file..

On Thu, Dec 1, 2016 at 3:09 PM Julian Hollingbery  wrote:
… or possibly running these checks in parallel?
 
Fra: Jaroslav Urik [mailto:jarda.u...@gmail.com] 
Sendt: 1. december 2016 14:36
Til: geoserver-users@lists.sourceforge.net
Emne: [Geoserver-users] GeoServer Slow to Start with Lots of Namespaces ( > 3h )
 
Hi, 
I have the same problem as described in [1] -- I am running GeoServer under 
Tomcat with a lot of georeferenced maps ( about 65 000 ) and it takes very long 
time to start - about 3-4 hours. 
The problem seems to be in that GeoServer is checking all of those resources 
one by one each time it starts..
My question is: Is there any way to disable these checks? Or do them only one a 
month or so? 
Or is there any other solution?
It is quite annoying when server needs to be restarted and people are waiting 
for it..
 
Thanks in advance
 
Jaroslav Urik
 
 
[1] 
http://osgeo-org.1560.x6.nabble.com/GeoServer-Slow-to-Start-with-Lots-of-Namespaces-td5068101.html
--
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

[Geoserver-users] app-schema and multi line segments

[kweis...@harris.com]

Hello all,
Has anyone had luck getting app-schema to encode a geometry with multiple 
segments?  I'm trying to map a single geometry entry in the DB to a gml:Curve 
with multiple LineStringSegments, but instead of multiple segments the 
app-schema appears to be concatenating them into a single segment with no 
breaks.  I have tried persisting the geometry as both MultiLineString and 
GeometryCollection(LineString, LineString) using PostGIS 2.2.2, but both 
experience the same incorrect output translation.  For example, this is the 
output I'm expecting:

http://www.opengis.net/gml/srs/epsg.xml#4052"; srsDimension="2" 
axisLabels="latitude longitude">
  

  42.1062 -82.4293 42.0936 -82.4319 
42.0803 -82.4344 42.0809 -82.4349 42.0670 -82.4381 42.0415 -82.4498 42.0297 
-82.4560


  42.3323 -82.4765 42.3232 -82.4714 
42.3113 -82.4643 42.3071 -82.4622 42.2936 -82.4569 42.2657 -82.4473 42.2515 
-82.4431 42.2431 -82.4404 42.2301 -82.4359 42.2179 -82.4331 42.2044 -82.4317 
42.1921 -82.4300

  


However, this is output from app-schema:

http://www.opengis.net/gml/srs/epsg.xml#4052";>
  


42.1062 -82.4293 42.0936 -82.4319 42.0803 -82.4344 42.0809 -82.4349 42.067 
-82.4381 42.0415 -82.4498 42.0297 -82.456 42.3323 -82.4765 42.3232 -82.4714 
42.3113 -82.4643 42.3071 -82.4622 42.2936 -82.4569 42.2657 -82.4473 42.2515 
-82.4431 42.2431 -82.4404 42.2301 -82.4359 42.2179 -82.4331 42.2044 -82.4317 
42.1921 -82.43


  


As you can see the two geometries are joined in a contiguous fashion which is 
undesirable.

If anyone has any ideas on how to achieve the desired result I would greatly 
appreciate it.

Thanks,

Kevin M. Weiss
Software Engineer
CRITICAL NETWORKS / HARRIS CORPORATION
harris.com  / kevin.we...@harris.com



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

Re: [Geoserver-users] App-Schema WMS Support

[kweis...@harris.com]

Hello Ben,

Thanks for the quick response.  I see what you mean about the location of the 
spatial element within the XML response structure.  Most of our schemas (which 
I do not control) bury it a few levels deep so I don't think the app-schema 
plugin will work for us unfortunately.

Thanks again for the help.

Kevin M. Weiss
Software Engineer
CRITICAL NETWORKS / HARRIS CORPORATION
harris.com  / kevin.we...@harris.com


-Original Message-
From: Ben Caradoc-Davies [mailto:b...@transient.nz] 
Sent: Tuesday, November 29, 2016 3:01 PM
To: Weiss, Kevin ; geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] App-Schema WMS Support

Kevin,

I expect that this is caused by the feature of interest lacking a geometry 
property at the top-level (an attribute in UML-speak). In the tutorial example, 
MappedFeature has a geometry property, but GeologicUnit has only an association 
with zero or more MappedFeatures that describe its location. For example, a 
geologic unit might be mapped as several outcrops (the gsml:occurrence 
association). Here is the UML from the GeoSciML 4.0 (the older version in the 
tutorial is similar):
http://www.geosciml.org/geosciml/4.0/documentation/html/index.htm?goto=1:3:1:105

I expect app-schema WMS to work for types that have a top-level geometry 
property. The WMS page also documents limitations on styling with properties 
from referenced features.

Kind regards,
Ben.

On 30/11/16 09:09, kweis...@harris.com wrote:
> Hello all,
> I'm trying to enable WMS support on an app-schema feature per the 
> instructions here 
> (http://docs.geoserver.org/latest/en/user/data/app-schema/wms-support.html).  
> The data is retrievable via WFS 2.0 requests, but when I try to request the 
> product via WMS the client receives a ServiceExceptionReport stating that 
> "Rendering process failed".  Inspecting the logs it appears to be resulting 
> from a NullPointerException in StreamingRenderer.java at line 2686.  Moving 
> up the stack I see a warn message stating that a transform exception occurred 
> when trying to de-project the current envelope.  It looks like it's trying to 
> transform the requested BBOX to a null projection.
>
> Naturally, I assumed I had screwed something up configuration-wise so I 
> imported the app-schema tutorial "gsml" workspace and restarted GeoServer to 
> test.  Oddly enough, "gsml:MappedFeature" displays properly via WMS, but 
> "gsml:GeologicUnit" causes the same error I saw with my own app-schema 
> mappings.  Has anyone else seen this behavior?  Am I missing some 
> configuration value somewhere or is this something I should report via the 
> bug tracker?
>
> The issue was originally discovered using GeoServer 2.9.2, but was replicated 
> in our environment using GeoServer 2.10.0 as well (using the appropriately 
> versioned plugins of course).
>
> Thanks,
>
> Kevin M. Weiss
> Software Engineer
> CRITICAL NETWORKS / HARRIS CORPORATION harris.com  / 
> kevin.we...@harris.com
>
>
> --
>  ___
> Geoserver-users mailing list
> Geoserver-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>

--
Ben Caradoc-Davies 
Director
Transient Software Limited <http://transient.nz/> New Zealand

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

[Geoserver-users] App-Schema WMS Support

[kweis...@harris.com]

Hello all,
I'm trying to enable WMS support on an app-schema feature per the instructions 
here 
(http://docs.geoserver.org/latest/en/user/data/app-schema/wms-support.html).  
The data is retrievable via WFS 2.0 requests, but when I try to request the 
product via WMS the client receives a ServiceExceptionReport stating that 
"Rendering process failed".  Inspecting the logs it appears to be resulting 
from a NullPointerException in StreamingRenderer.java at line 2686.  Moving up 
the stack I see a warn message stating that a transform exception occurred when 
trying to de-project the current envelope.  It looks like it's trying to 
transform the requested BBOX to a null projection.

Naturally, I assumed I had screwed something up configuration-wise so I 
imported the app-schema tutorial "gsml" workspace and restarted GeoServer to 
test.  Oddly enough, "gsml:MappedFeature" displays properly via WMS, but 
"gsml:GeologicUnit" causes the same error I saw with my own app-schema 
mappings.  Has anyone else seen this behavior?  Am I missing some configuration 
value somewhere or is this something I should report via the bug tracker?

The issue was originally discovered using GeoServer 2.9.2, but was replicated 
in our environment using GeoServer 2.10.0 as well (using the appropriately 
versioned plugins of course).

Thanks,

Kevin M. Weiss
Software Engineer
CRITICAL NETWORKS / HARRIS CORPORATION
harris.com  / kevin.we...@harris.com


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

[Geoserver-users] App-Schema aliasing

[kweis...@harris.com]

Hello all,

I was wondering if anyone knows of a way to associate multiple feature types 
with a single top level element via app-schema.  The issue I'm running into is 
that multiple different data sets are expressed using the same top level 
element in the WXXM 2.0 schema.  It seems that the app schema requires the 
feature name to exactly match the expected top level object and therefore must 
be unique.  Is there any way to alias this or modify our configuration so that 
different features could share a common XML return structure (with different 
data sources behind the scenes of course)?

Thanks for any help.

Kevin M. Weiss
Software Engineer
CRITICAL NETWORKS / HARRIS CORPORATION
harris.com  / kevin.we...@harris.com


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

[Geoserver-users] NetCDF-out time & elevation dimension question

[kweis...@harris.com]

Hey all,
I think I stumbled across a bug in the time & elevation dimension handling of 
the NetCDF-out extension.  Our source data contains elevations in Pascals and 
so we configured the elevation dimension accordingly under the "Dimensions" 
tab.  When I execute a DescribeCoverage request for the coverage, the Elevation 
domain is correctly labled with uom="Pa".  However, when I execute a 
getCoverage request, the response data defines the elevation units as "m".  
Looking through the source code I think the bug may be caused by something as 
trivial as the capitalization (or lack thereof) used for the enabledDimensions 
key in org.geoserver.wcs2_0.response.WCSDimensionsSubsetHelper.java.  The 
"setupDimensions()" method calls "setupDimensionBean()" for both time & 
elevation dimensions using all caps.  As I step through the code in the 
debugger, my enabledDimensions map contains both "time" and "elevation" as 
lower case keys.  The result is that the dimension is not retrieved from the 
map of enabledDimensions and the "fallback" case is hit which uses default 
values for unit type and symbol.

I have tried modifying the coverage.xml to use capital names for time & 
elevation dimensions, but this causes GeoServer to ignore the dimensions 
altogether.  Am I configuring my GeoServer incorrectly or is this an actual bug?

Also, and this is a slightly unrelated question, is there a way to provide 
additional attributes to a dimensions output?  As stated before, my source data 
contains elevation info in Pascals.  I would like to output the following 
attributes under my elevation dimensions if possible:
positive = "down"
long_name = "Isobaric surface"
standard_name = "air_pressure"

Thanks,

Kevin M. Weiss
Software Engineer
CRITICAL NETWORKS / HARRIS CORPORATION
harris.com  / kevin.we...@harris.com



--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] NetCDF Compression Settings

[kweis...@harris.com]

Hi Daniele,
I got finally got a chance to look into the NetCDF Output code.  It appears the 
issue is due to the writer being created before the parseParams call in the 
NetCDFOutputManager constructor.  The private attribute “compressionLevel” is 
defaulted to “0” during instantiation and then used in the getWriter call.  
However the “parseParams” call which immediately follows the creation of the 
writer object is where the system configuration is read and the 
“compressionLevel” value is properly set.

I see you created a bug ticket.  I’ll add a comment with my findings.

Thanks,

Kevin M. Weiss
Software Engineer
CRITICAL NETWORKS / HARRIS CORPORATION
harris.com  / kevin.we...@harris.com


From: dany.geoto...@gmail.com [mailto:dany.geoto...@gmail.com] On Behalf Of 
Daniele Romagnoli
Sent: Wednesday, February 03, 2016 11:38 AM
To: Weiss, Kevin 
Cc: geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] NetCDF Compression Settings

Hi Kevin,
We had this working when specifying NetCDF4-classic output format.
I will check that in the next days looking for any regression occurred in the 
meantime. 

Cheers,
Daniele

On Wed, Feb 3, 2016 at 3:51 PM, kweis...@harris.com  wrote:
Hello,

Sorry for posting this twice, but I think my first attempt was hidden due to 
Outlook's preference of sending HTML mail.

I'm trying to enable NetCDF compression via the NetCDF Output plugin in 
GeoServer 2.8.1.  I have set a compression value (5) in both the individual 
layer settings as well as the global settings; however, all WCS 2.0.1 
NetCDF4-Classic responses appear to be the uncompressed file size.

I believe I have verified that they are uncompressed by running the following 
command:
`ncdump -h -s  | grep DeflateLevel`

Sample files which are known to be compressed respond with their compression 
level, but the GeoServer responses do not display anything.

Is there a step I could be missing to enable compression?  Has anyone else 
gotten this working?

Thanks,

Kevin M. Weiss
Software Engineer
CRITICAL NETWORKS / HARRIS CORPORATION
harris.com  / kevin.we...@harris.com


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users




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

Ing. Daniele Romagnoli
Senior Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax:  +39 0584 1660272

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.

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM

Re: [Geoserver-users] NetCDF Compression Settings

[kweis...@harris.com]

Hello,

Sorry for posting this twice, but I think my first attempt was hidden due to 
Outlook's preference of sending HTML mail.

I'm trying to enable NetCDF compression via the NetCDF Output plugin in 
GeoServer 2.8.1.  I have set a compression value (5) in both the individual 
layer settings as well as the global settings; however, all WCS 2.0.1 
NetCDF4-Classic responses appear to be the uncompressed file size.

I believe I have verified that they are uncompressed by running the following 
command:
`ncdump -h -s  | grep DeflateLevel`

Sample files which are known to be compressed respond with their compression 
level, but the GeoServer responses do not display anything.

Is there a step I could be missing to enable compression?  Has anyone else 
gotten this working?

Thanks,

Kevin M. Weiss
Software Engineer
CRITICAL NETWORKS / HARRIS CORPORATION
harris.com  / kevin.we...@harris.com


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

[Geoserver-users] NetCDF Compression Settings

[kweis...@harris.com]

Hello,
I'm trying to enable NetCDF compression via the NetCDF Output plugin in 
GeoServer 2.8.1.  I have set a compression value (5) in both the individual 
layer settings as well as the global settings; however, all WCS 2.0.1 
NetCDF4-Classic responses appear to be the uncompressed file size.

I believe I have verified that they are uncompressed by running the following 
command:
`ncdump -h -s  | grep DeflateLevel`

Sample files which are known to be compressed respond with their compression 
level, but the GeoServer responses do not display anything.

Is there a step I could be missing to enable compression?  Has anyone else 
gotten this working?

Thanks,

Kevin M. Weiss
Software Engineer
Critical Networks / HARRIS CORPORATION
harris.com  / kevin.we...@harris.com
[Harris_wR_2color_72dpi.jpg]

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

[Geoserver-users] Multidimensional NetCDF coverage optimization

[kweis...@harris.com]

Hello all,
I noticed an inefficiency in the way GeoServer serves multi-dimensional 
coverage data and was curious if there was a way to optimize it without 
completely ripping out all the "plumbing" per se.  The inefficiency occurs when 
requesting multiple coverage dimensions from an ImageMosaic data store where 
two or more of the requested dimensions exist within the same source file.  For 
example, requesting all elevations of a Temperature data coverage that are all 
housed in the same NetCDF file on disk.
GeoServer fields the request by querying the DB for granules that meet the 
criteria.  Each granule contains a location of the source file containing that 
granule's data.  In the above case, the result is a list of granules that all 
point to the same file on disk.  GeoServer then iterates over each granule, 
opening the file, reading the contents for one specific dimension slice, and 
then closing the file.  Herein lies the problem.  The IO required to repeatedly 
open & close the source file can dramatically increase the system's response 
time.
As an example, a request for a single elevation in my test system takes 0.1 
seconds to complete.  A request for all 25 elevations from a single file 
balloons the response time to 3.3 seconds.  All times were calculated via CLI 
client (time curl ...) so they would include network latency of transferring a 
larger file in the latter test, however the metrics were gathered directly on 
the host system so network IO should have been minimal.

Has anyone else seen this?  Is it possible to optimize without completely 
reworking the GetCoverage & geotools implementations?

Any advice would be helpful.

Thanks,

Kevin M. Weiss
Software Engineer
Critical Networks / HARRIS CORPORATION

[Harris_wR_2color_72dpi.jpg]

--
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] NetCDF Model WCS Question

[kweis...@harris.com]

Daniele,
You hit the nail on the head and I feel a bit foolish.   I had even reproduced 
the issue standing up another server, but I guess both times I forgot to 
configured the additional dimensions for all but the first layer.

Thanks for the help!

-Kevin

From: dany.geoto...@gmail.com [mailto:dany.geoto...@gmail.com] On Behalf Of 
Daniele Romagnoli
Sent: Wednesday, October 14, 2015 2:36 AM
To: Weiss, Kevin 
Cc: geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] NetCDF Model WCS Question

Dear Kevin,
do you have a more detailed log for that?

Did you also configure all the available dimensions for the other layers, from 
the Dimension Tab of the layer config?
Please, let us know.
Best Regards,
Daniele



On Tue, Oct 13, 2015 at 6:35 PM, 
kweis...@harris.com<mailto:kweis...@harris.com> 
mailto:kweis...@harris.com>> wrote:
Hello all,
I’ve been testing the 2.8-RC build to see if the updated NetCDF support (both 
netcdf and netcdf-output plugins) could provide the functionality we need.  Our 
use case involves hosting 1-n NetCDF model forecast files and providing both 
WMS and WCS access in different projections.  In my test setup I created an 
ImageMosaic store with sub-directories for each parameter.  After publishing 
the necessary layers I am able to visualize each different parameter via the 
Layer Preview, however it seems that WCS only works for the first layer 
published from the Store.  WCS 2.0.1 requests for other layers from the Store 
result in the exception text of “Failed to read the coverage xxx”.

The server throws a stacktrace with the following errors:

ERROR [geoserver.ows] -
org.geoserver.wcs2_0.exception.WCS20Exception: Failed to read the coverage xxx
…
Caused by: java.lang.NullPointerException
at 
org.geoserver.wcs2_0.response.WCSDimensionsSubsetHelper.setupDimensionBean(WCSDimensionsSubsetHelper.java:1339)

Has anyone else seen this issue?

Thanks,
-Kevin

--

___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net<mailto:Geoserver-users@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/geoserver-users



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

Ing. Daniele Romagnoli
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://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.

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

[Geoserver-users] NetCDF Model WCS Question

[kweis...@harris.com]

Hello all,
I've been testing the 2.8-RC build to see if the updated NetCDF support (both 
netcdf and netcdf-output plugins) could provide the functionality we need.  Our 
use case involves hosting 1-n NetCDF model forecast files and providing both 
WMS and WCS access in different projections.  In my test setup I created an 
ImageMosaic store with sub-directories for each parameter.  After publishing 
the necessary layers I am able to visualize each different parameter via the 
Layer Preview, however it seems that WCS only works for the first layer 
published from the Store.  WCS 2.0.1 requests for other layers from the Store 
result in the exception text of "Failed to read the coverage xxx".

The server throws a stacktrace with the following errors:

ERROR [geoserver.ows] -
org.geoserver.wcs2_0.exception.WCS20Exception: Failed to read the coverage xxx
...
Caused by: java.lang.NullPointerException
at 
org.geoserver.wcs2_0.response.WCSDimensionsSubsetHelper.setupDimensionBean(WCSDimensionsSubsetHelper.java:1339)

Has anyone else seen this issue?

Thanks,
-Kevin
--
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users