[Geoserver-users] WFS will not read the same date that it stores
Using GeoServer2.8 I'm having a very basic problem with WFS-T inserting a feature that has date fields. When I do a GetFeature to retrieve the date I inserted, I get a value that's one-day prior to the date I inserted. This appears to be related to the GeoTools xsDateTimeFormat class used to read the incoming XML on my insert-request and the code's assumption that the incoming date is in the GMT timezone. Do clients of WFS have to convert all their dates to GMT before inserting them?? Here is an example transaction that I use for insert... http://www.opengis.net/wfs"; xmlns:gml="http://www.opengis.net/gml"; xmlns:ogc="http://www.opengis.net/ogc"; version="1.0.0" service="WFS"> 2016-01-04 Then I read it back with... http://www.opengis.net/wfs"; xmlns:fdot="http://byers.com/nxwx/solution/fdot"; xmlns:gml="http://www.opengis.net/gml"; xmlns:ogc="http://www.opengis.net/ogc"; version="1.0.0" service="WFS" outputFormat="JSON"> In the JSON output I find... "INSTALLED_DATE":"2016-01-03Z" So I stored 1/4/2016, I read back 1/3/2016. My back-end datastore is Oracle. When I select directly from the database I find the wrong value there too. SELECT TO_CHAR(installed_date, 'dd-mon- hh24:mi:ss')... This gives me... 03-jan-2016 19:00:00. How do I set things up so a WFS client that stores 1/4/2016 gets 1/4/2016 back? -- 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] WFS will not read the same date that it stores
The GeoTools/GeoServer data handler should use the timezone of the server (so if that is set to GMT then you need to convert before sending). This allows for servers where clients can be in multiple timezones and need to agree a fixed timezone when communicating with the server. If you are the only user of the client/server then you should be able to set the timezone on the server and client to the same one and it should all just work (tm). Ian On 13 October 2016 at 14:33, Walter Stovall wrote: > Using GeoServer2.8 I’m having a very basic problem with WFS-T inserting a > feature that has date fields. When I do a GetFeature to retrieve the date > I inserted, I get a value that’s one-day prior to the date I inserted. > This appears to be related to the GeoTools xsDateTimeFormat class used to > read the incoming XML on my insert-request and the code’s assumption that > the incoming date is in the GMT timezone. Do clients of WFS have to > convert all their dates to GMT before inserting them?? > > > > Here is an example transaction that I use for insert… > > > > > xmlns="http://www.opengis.net/wfs"; > > xmlns:gml="http://www.opengis.net/gml"; > > xmlns:ogc="http://www.opengis.net/ogc"; > > version="1.0.0" > > service="WFS"> > > > > > > 2016-01-04 > > > > > > > > > > Then I read it back with… > > > > > xmlns="http://www.opengis.net/wfs"; > > xmlns:fdot="http://byers.com/nxwx/solution/fdot"; > > xmlns:gml="http://www.opengis.net/gml"; > > xmlns:ogc="http://www.opengis.net/ogc"; > > version="1.0.0" > > service="WFS" > > outputFormat="JSON"> > > > > > > > > > > > > > > > > In the JSON output I find… > > "INSTALLED_DATE":"2016-01-03Z" > > > > So I stored 1/4/2016, I read back 1/3/2016. > > > > My back-end datastore is Oracle. When I select directly from the database > I find the wrong value there too. > > SELECT TO_CHAR(installed_date, 'dd-mon- hh24:mi:ss')… > > > > This gives me… 03-jan-2016 19:00:00. > > > > How do I set things up so a WFS client that stores 1/4/2016 gets 1/4/2016 > back? > > > -- > 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 > > -- Ian Turton -- 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] WFS will not read the same date that it stores
Thanks for the advice. Unfortunately following that path does not work for me.
I still end up with dates that are one-behind.
This was discovered with a more complicated arrangement, but I have this
problem in my simple test environment where my geoserver is deployed to a local
tomcat 8 on my Windows workstation. This is a computer setup for Eastern
Standard Daylight time (which is an offset of -05:00).
I browse to my http://localhost:8080/geoserver/web webapp and run the Demo page
where I paste in the WFS-T Insert request I showed earlier that inserts a date
of 01/04/2016. Then I see a new row has showed up in my back-end Oracle table
where geoserver is storing these features with the OracleNGDataStore.
Selecting the date from that row, I get 01/03/2016. If I drill down by asking
Oracle to show the time too I’ll get 03-jan-2016 19:00:00. So obviously
“somebody” is applying the -05:00 offset by the time the data is given to the
Oracle driver. fwiw the Oracle dbtimezone is -04:00 but that hardly matters
because Oracle expects to be given the data in the “correct” timezone and just
stores what you give it.
I’ve already discovered by watching the geoserver log that Oracle is receiving
the wrong value.
To find out more I build an eclipse workspace that includes geoserver and
geotools and attach to the running tomcat.
So first I break in the debugger at SimpleFeatureImpl which is getting hit by
the SAX parsing invoked by WfsXmlReader. The values object array there has a
date of “2016-01-03” (which is the toString output of Gregorian$Date with a
fastTime of 145186560). This is ultimately going to become Jan 3 19:00
stored in Oracle. So I know things are bad already.
Backtracking to see where things went wrong I back all the way up to where the
Jan 4 date is getting parsed out of the XML for my WFS-T insert request. I
stop at XsDateTimeFormat.parseObject(String, ParsePosition, boolean) and in
there I see where there’s an assumption that the timezone will ALWAYS be GMT…
if (parseTime) {
tz = TimeZone.getTimeZone(digits.toString());
} else {
// there's no meaning for timezone if not parsing time
// http://en.wikipedia.org/wiki/ISO_8601
tz = TimeZone.getTimeZone("GMT");
}
Calendar cal = Calendar.getInstance(tz);
So regardless of environment variables etc. I know that at this stage my
incoming date is always represented as Jan 4 2016 GMT. It would appear that
later this gets represented as EDT (my timezone) and becomes Jan 3 19:00.
So I patched my code just now to call TimeZone.getDefault() instead of using
“GMT” specifically. Now what gets stored in my database is correct, Jan 4
00:00.
As to whether this specifically is a fix and whether similar problems wait for
me with datetime vs. just date, I’m unclear at this point.
What are your thoughts about this? Do I have a way to make it work without a
code change?
Thanks for your help Ian!
Regards Walter Stovall
From: Ian Turton [mailto:ijtur...@gmail.com]
Sent: Thursday, October 13, 2016 9:54 AM
To: Walter Stovall
Cc: geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] WFS will not read the same date that it stores
The GeoTools/GeoServer data handler should use the timezone of the server (so
if that is set to GMT then you need to convert before sending). This allows for
servers where clients can be in multiple timezones and need to agree a fixed
timezone when communicating with the server.
If you are the only user of the client/server then you should be able to set
the timezone on the server and client to the same one and it should all just
work (tm).
Ian
On 13 October 2016 at 14:33, Walter Stovall
mailto:walter.stov...@byers.com>> wrote:
Using GeoServer2.8 I’m having a very basic problem with WFS-T inserting a
feature that has date fields. When I do a GetFeature to retrieve the date I
inserted, I get a value that’s one-day prior to the date I inserted. This
appears to be related to the GeoTools xsDateTimeFormat class used to read the
incoming XML on my insert-request and the code’s assumption that the incoming
date is in the GMT timezone. Do clients of WFS have to convert all their dates
to GMT before inserting them??
Here is an example transaction that I use for insert…
http://www.opengis.net/wfs";
xmlns:gml="http://www.opengis.net/gml";
xmlns:ogc="http://www.opengis.net/ogc";
version="1.0.0"
service="WFS">
2016-01-04
Then I read it back with…
http://www.opengis.net/wfs";
xmlns:fdot="http://byers.com/nxwx/solution/fdot";
xmlns:gml="http://www.opengis.net/gml";
xmlns:ogc="http://www.opengis.net/ogc";
version="1.0.0"
service="WFS"
outputFormat="JSON">
In the JSON output I find…
"INSTALLED_DATE":"2016-01-03Z"
So I stored 1/4/2016, I read back 1/3/2016.
My back-end datastore is Oracle. When I select directly from the database I
Re: [Geoserver-users] WFS GetCapabilities failures
i believe what i'm seeing is explained by https://osgeo-org.atlassian.net/browse/GEOS-7216 On Wed, 28 Sep 2016 12:32:57 +1000, Raif S. Naffah wrote: > hi all, > > working w/ GeoServer 2.8.5 i'm getting sporadic failures when > requesting WFS capabilities. the failures show up in the > geoserver.log as follows: > > 2016-09-28 12:02:18,843 INFO [org.geoserver.wfs] - > Request: getServiceInfo > 2016-09-28 12:02:18,844 INFO [org.geoserver.wfs] - > Request: getCapabilities > baseUrl = http://localhost:9100/geoserver/ > service = WFS > 2016-09-28 12:02:18,879 ERROR [org.geoserver.ows] - > java.io.IOException > at > org.geoserver.wfs.response.GetCapabilitiesResponse.write(GetCapabilitiesResponse.java:63) > at org.geoserver.ows.Dispatcher.response(Dispatcher.java:996) at > org.geoserver.ows.Dispatcher.handleRequestInternal(Dispatcher.java:279) > at > org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:153) > at > org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:48) > at > org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:923) > at > org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:852) > at > org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:882) > at > org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:778) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) at > javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at > org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1093) > at > org.geoserver.filters.ThreadLocalsCleanupFilter.doFilter(ThreadLocalsCleanupFilter.java:28) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084) > at > org.geoserver.filters.SpringDelegatingFilter$Chain.doFilter(SpringDelegatingFilter.java:75) > at > org.geoserver.wms.animate.AnimatorFilter.doFilter(AnimatorFilter.java:71) > at > org.geoserver.filters.SpringDelegatingFilter$Chain.doFilter(SpringDelegatingFilter.java:71) > at > org.geoserver.filters.SpringDelegatingFilter.doFilter(SpringDelegatingFilter.java:46) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084) > at > org.geoserver.platform.AdvancedDispatchFilter.doFilter(AdvancedDispatchFilter.java:50) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084) > at > org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:311) > at > org.geoserver.security.filter.GeoServerCompositeFilter$NestedFilterChain.doFilter(GeoServerCompositeFilter.java:69) > at > org.springframework.security.web.access.intercept.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:116) > at > org.springframework.security.web.access.intercept.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:83) > at > org.geoserver.security.filter.GeoServerCompositeFilter$NestedFilterChain.doFilter(GeoServerCompositeFilter.java:73) > at > org.geoserver.security.filter.GeoServerCompositeFilter.doFilter(GeoServerCompositeFilter.java:92) > at > org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:323) > at > org.geoserver.security.filter.GeoServerCompositeFilter$NestedFilterChain.doFilter(GeoServerCompositeFilter.java:69) > at > org.springframework.security.web.access.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:113) > at > org.geoserver.security.filter.GeoServerCompositeFilter$NestedFilterChain.doFilter(GeoServerCompositeFilter.java:73) > at > org.geoserver.security.filter.GeoServerCompositeFilter.doFilter(GeoServerCompositeFilter.java:92) > at > org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:323) > at > org.geoserver.security.filter.GeoServerAnonymousAuthenticationFilter.doFilter(GeoServerAnonymousAuthenticationFilter.java:54) > at > org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:323) > at > org.geoserver.security.filter.GeoServerCompositeFilter$NestedFilterChain.doFilter(GeoServerCompositeFilter.java:69) > at > org.springframework.security.web.authentication.www.BasicAuthenticationFilter.doFilter(BasicAuthenticationFilter.java:150) > at > org.geoserver.security.filter.GeoServerCompositeFilter$NestedFilterChain.doFilter(GeoServerCompositeFilter.java:73) > at > org.geoserver.security.filter.GeoServerCompositeFilter.doFilter(GeoServerCompositeFilter.java:92) > at > org.geoserver.security.filter.GeoServerBasicAuthenticationFilter.doFilter(GeoServerBasicAuthenticationFilter.java:83) > at > org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java
Re: [Geoserver-users] WFS GetCapabilities failures
So are you configuring geometryless layers via the REST interface? The UI should not allow null bounding boxes even on geometryless layers. Cheers Andrea On Thu, Oct 13, 2016 at 6:45 PM, Raif S. Naffah wrote: > i believe what i'm seeing is explained by > > https://osgeo-org.atlassian.net/browse/GEOS-7216 > > > On Wed, 28 Sep 2016 12:32:57 +1000, Raif S. Naffah wrote: > > > hi all, > > > > working w/ GeoServer 2.8.5 i'm getting sporadic failures when > > requesting WFS capabilities. the failures show up in the > > geoserver.log as follows: > > > > 2016-09-28 12:02:18,843 INFO [org.geoserver.wfs] - > > Request: getServiceInfo > > 2016-09-28 12:02:18,844 INFO [org.geoserver.wfs] - > > Request: getCapabilities > > baseUrl = http://localhost:9100/geoserver/ > > service = WFS > > 2016-09-28 12:02:18,879 ERROR [org.geoserver.ows] - > > java.io.IOException > > at > > org.geoserver.wfs.response.GetCapabilitiesResponse.write( > GetCapabilitiesResponse.java:63) > > at org.geoserver.ows.Dispatcher.response(Dispatcher.java:996) at > > org.geoserver.ows.Dispatcher.handleRequestInternal(Dispatcher.java:279) > > at > > org.springframework.web.servlet.mvc.AbstractController.handleRequest( > AbstractController.java:153) > > at > > org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter > .handle(SimpleControllerHandlerAdapter.java:48) > > at > > org.springframework.web.servlet.DispatcherServlet. > doDispatch(DispatcherServlet.java:923) > > at > > org.springframework.web.servlet.DispatcherServlet. > doService(DispatcherServlet.java:852) > > at > > org.springframework.web.servlet.FrameworkServlet.processRequest( > FrameworkServlet.java:882) > > at > > org.springframework.web.servlet.FrameworkServlet. > doGet(FrameworkServlet.java:778) > > at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) at > > javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at > > org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487) > > at > > org.mortbay.jetty.servlet.ServletHandler$CachedChain. > doFilter(ServletHandler.java:1093) > > at > > org.geoserver.filters.ThreadLocalsCleanupFilter.doFilter( > ThreadLocalsCleanupFilter.java:28) > > at > > org.mortbay.jetty.servlet.ServletHandler$CachedChain. > doFilter(ServletHandler.java:1084) > > at > > org.geoserver.filters.SpringDelegatingFilter$Chain.doFilter( > SpringDelegatingFilter.java:75) > > at > > org.geoserver.wms.animate.AnimatorFilter.doFilter( > AnimatorFilter.java:71) > > at > > org.geoserver.filters.SpringDelegatingFilter$Chain.doFilter( > SpringDelegatingFilter.java:71) > > at > > org.geoserver.filters.SpringDelegatingFilter.doFilter( > SpringDelegatingFilter.java:46) > > at > > org.mortbay.jetty.servlet.ServletHandler$CachedChain. > doFilter(ServletHandler.java:1084) > > at > > org.geoserver.platform.AdvancedDispatchFilter.doFilter( > AdvancedDispatchFilter.java:50) > > at > > org.mortbay.jetty.servlet.ServletHandler$CachedChain. > doFilter(ServletHandler.java:1084) > > at > > org.springframework.security.web.FilterChainProxy$ > VirtualFilterChain.doFilter(FilterChainProxy.java:311) > > at > > org.geoserver.security.filter.GeoServerCompositeFilter$ > NestedFilterChain.doFilter(GeoServerCompositeFilter.java:69) > > at > > org.springframework.security.web.access.intercept. > FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:116) > > at > > org.springframework.security.web.access.intercept. > FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:83) > > at > > org.geoserver.security.filter.GeoServerCompositeFilter$ > NestedFilterChain.doFilter(GeoServerCompositeFilter.java:73) > > at > > org.geoserver.security.filter.GeoServerCompositeFilter.doFilter( > GeoServerCompositeFilter.java:92) > > at > > org.springframework.security.web.FilterChainProxy$ > VirtualFilterChain.doFilter(FilterChainProxy.java:323) > > at > > org.geoserver.security.filter.GeoServerCompositeFilter$ > NestedFilterChain.doFilter(GeoServerCompositeFilter.java:69) > > at > > org.springframework.security.web.access.ExceptionTranslationFilter. > doFilter(ExceptionTranslationFilter.java:113) > > at > > org.geoserver.security.filter.GeoServerCompositeFilter$ > NestedFilterChain.doFilter(GeoServerCompositeFilter.java:73) > > at > > org.geoserver.security.filter.GeoServerCompositeFilter.doFilter( > GeoServerCompositeFilter.java:92) > > at > > org.springframework.security.web.FilterChainProxy$ > VirtualFilterChain.doFilter(FilterChainProxy.java:323) > > at > > org.geoserver.security.filter.GeoServerAnonymousAuthenticati > onFilter.doFilter(GeoServerAnonymousAuthenticationFilter.java:54) > > at > > org.springframework.security.web.FilterChainProxy$ > VirtualFilterChain.doFilter(FilterChainProxy.java:323) > > at > > org.geoserver.security.filter.GeoServerCompositeFilter$ > NestedFilterChain.doFilter(GeoServerCompositeFilter.java:69) > > at > > org.springframework.security.web.authentication.www. > BasicAuthenticationFilter.doFilter(BasicAut
Re: [Geoserver-users] WFS will not read the same date that it stores
That sounds like a regression to me, when I'm back at my desk, I'll dig out
the previous tests and check how that slipped in.
Can you raise a bug in the meantime so I don't forget.
Ian
On 13 Oct 2016 16:28, "Walter Stovall" wrote:
> Thanks for the advice. Unfortunately following that path does not work for
> me. I still end up with dates that are one-behind.
>
>
>
> This was discovered with a more complicated arrangement, but I have this
> problem in my simple test environment where my geoserver is deployed to a
> local tomcat 8 on my Windows workstation. This is a computer setup for
> Eastern Standard Daylight time (which is an offset of -05:00).
>
>
>
> I browse to my http://localhost:8080/geoserver/web webapp and run the
> Demo page where I paste in the WFS-T Insert request I showed earlier that
> inserts a date of 01/04/2016. Then I see a new row has showed up in my
> back-end Oracle table where geoserver is storing these features with the
> OracleNGDataStore. Selecting the date from that row, I get 01/03/2016. If
> I drill down by asking Oracle to show the time too I’ll get 03-jan-2016
> 19:00:00. So obviously “somebody” is applying the -05:00 offset by the
> time the data is given to the Oracle driver. fwiw the Oracle dbtimezone is
> -04:00 but that hardly matters because Oracle expects to be given the data
> in the “correct” timezone and just stores what you give it.
>
>
>
> I’ve already discovered by watching the geoserver log that Oracle is
> receiving the wrong value.
>
>
>
> To find out more I build an eclipse workspace that includes geoserver and
> geotools and attach to the running tomcat.
>
> So first I break in the debugger at SimpleFeatureImpl which is getting hit
> by the SAX parsing invoked by WfsXmlReader. The *values* object array
> there has a date of “2016-01-03” (which is the toString output of
> Gregorian$Date with a fastTime of 145186560). This is ultimately going
> to become Jan 3 19:00 stored in Oracle. So I know things are bad already.
>
>
>
> Backtracking to see where things went wrong I back all the way up to where
> the Jan 4 date is getting parsed out of the XML for my WFS-T insert
> request. I stop at XsDateTimeFormat.parseObject(String, ParsePosition,
> boolean) and in there I see where there’s an assumption that the timezone
> will ALWAYS be GMT…
>
>
>
> *if* (parseTime) {
>
> tz = TimeZone.*getTimeZone*(digits.toString());
>
> } *else* {
>
> // there's no meaning for timezone if not parsing time
>
> // http://en.wikipedia.org/wiki/ISO_8601
>
> tz = TimeZone.*getTimeZone*("GMT");
>
> }
>
> Calendar cal = Calendar.*getInstance*(tz);
>
>
>
> So regardless of environment variables etc. I know that at this stage my
> incoming date is always represented as Jan 4 2016 GMT. It would appear
> that later this gets represented as EDT (my timezone) and becomes Jan 3
> 19:00.
>
>
>
> So I patched my code just now to call TimeZone.getDefault() instead of
> using “GMT” specifically. Now what gets stored in my database is correct,
> Jan 4 00:00.
>
>
>
> As to whether this specifically is a fix and whether similar problems wait
> for me with datetime vs. just date, I’m unclear at this point.
>
>
>
> What are your thoughts about this? Do I have a way to make it work
> without a code change?
>
>
>
> Thanks for your help Ian!
>
>
>
> Regards Walter Stovall
>
>
>
> *From:* Ian Turton [mailto:ijtur...@gmail.com]
> *Sent:* Thursday, October 13, 2016 9:54 AM
> *To:* Walter Stovall
> *Cc:* geoserver-users@lists.sourceforge.net
> *Subject:* Re: [Geoserver-users] WFS will not read the same date that it
> stores
>
>
>
> The GeoTools/GeoServer data handler should use the timezone of the server
> (so if that is set to GMT then you need to convert before sending). This
> allows for servers where clients can be in multiple timezones and need to
> agree a fixed timezone when communicating with the server.
>
>
>
> If you are the only user of the client/server then you should be able to
> set the timezone on the server and client to the same one and it should all
> just work (tm).
>
>
>
> Ian
>
>
>
> On 13 October 2016 at 14:33, Walter Stovall
> wrote:
>
> Using GeoServer2.8 I’m having a very basic problem with WFS-T inserting a
> feature that has date fields. When I do a GetFeature to retrieve the date
> I inserted, I get a value that’s one-day prior to the date I inserted.
> This appears to be related to the GeoTools xsDateTimeFormat class used to
> read the incoming XML on my insert-request and the code’s assumption that
> the incoming date is in the GMT timezone. Do clients of WFS have to
> convert all their dates to GMT before inserting them??
>
>
>
> Here is an example transaction that I use for insert…
>
>
>
>
> xmlns="http://www.opengis.net/wfs";
>
> xmlns:gml="http://www.opengis.net/gml";
>
> xmlns:ogc="http://www.opengis.net/ogc";
>
> version="1.0.0"
>
> service="WFS">
>
>
>
>
Re: [Geoserver-users] WFS will not read the same date that it stores
Ian, going by memory and answering from my tablet... didn't someone
contribute a patch to make
dates timezone independent? With a system variable to set that?
Cheers
Andrea
On Thu, Oct 13, 2016 at 8:22 PM, Ian Turton wrote:
> That sounds like a regression to me, when I'm back at my desk, I'll dig
> out the previous tests and check how that slipped in.
>
> Can you raise a bug in the meantime so I don't forget.
>
> Ian
>
> On 13 Oct 2016 16:28, "Walter Stovall" wrote:
>
>> Thanks for the advice. Unfortunately following that path does not work
>> for me. I still end up with dates that are one-behind.
>>
>>
>>
>> This was discovered with a more complicated arrangement, but I have this
>> problem in my simple test environment where my geoserver is deployed to a
>> local tomcat 8 on my Windows workstation. This is a computer setup for
>> Eastern Standard Daylight time (which is an offset of -05:00).
>>
>>
>>
>> I browse to my http://localhost:8080/geoserver/web webapp and run the
>> Demo page where I paste in the WFS-T Insert request I showed earlier that
>> inserts a date of 01/04/2016. Then I see a new row has showed up in my
>> back-end Oracle table where geoserver is storing these features with the
>> OracleNGDataStore. Selecting the date from that row, I get 01/03/2016. If
>> I drill down by asking Oracle to show the time too I’ll get 03-jan-2016
>> 19:00:00. So obviously “somebody” is applying the -05:00 offset by the
>> time the data is given to the Oracle driver. fwiw the Oracle dbtimezone is
>> -04:00 but that hardly matters because Oracle expects to be given the data
>> in the “correct” timezone and just stores what you give it.
>>
>>
>>
>> I’ve already discovered by watching the geoserver log that Oracle is
>> receiving the wrong value.
>>
>>
>>
>> To find out more I build an eclipse workspace that includes geoserver and
>> geotools and attach to the running tomcat.
>>
>> So first I break in the debugger at SimpleFeatureImpl which is getting
>> hit by the SAX parsing invoked by WfsXmlReader. The *values* object
>> array there has a date of “2016-01-03” (which is the toString output of
>> Gregorian$Date with a fastTime of 145186560). This is ultimately going
>> to become Jan 3 19:00 stored in Oracle. So I know things are bad already.
>>
>>
>>
>> Backtracking to see where things went wrong I back all the way up to
>> where the Jan 4 date is getting parsed out of the XML for my WFS-T insert
>> request. I stop at XsDateTimeFormat.parseObject(String, ParsePosition,
>> boolean) and in there I see where there’s an assumption that the timezone
>> will ALWAYS be GMT…
>>
>>
>>
>> *if* (parseTime) {
>>
>> tz = TimeZone.*getTimeZone*(digits.toString());
>>
>> } *else* {
>>
>> // there's no meaning for timezone if not parsing time
>>
>> // http://en.wikipedia.org/wiki/ISO_8601
>>
>> tz = TimeZone.*getTimeZone*("GMT");
>>
>> }
>>
>> Calendar cal = Calendar.*getInstance*(tz);
>>
>>
>>
>> So regardless of environment variables etc. I know that at this stage my
>> incoming date is always represented as Jan 4 2016 GMT. It would appear
>> that later this gets represented as EDT (my timezone) and becomes Jan 3
>> 19:00.
>>
>>
>>
>> So I patched my code just now to call TimeZone.getDefault() instead of
>> using “GMT” specifically. Now what gets stored in my database is correct,
>> Jan 4 00:00.
>>
>>
>>
>> As to whether this specifically is a fix and whether similar problems
>> wait for me with datetime vs. just date, I’m unclear at this point.
>>
>>
>>
>> What are your thoughts about this? Do I have a way to make it work
>> without a code change?
>>
>>
>>
>> Thanks for your help Ian!
>>
>>
>>
>> Regards Walter Stovall
>>
>>
>>
>> *From:* Ian Turton [mailto:ijtur...@gmail.com]
>> *Sent:* Thursday, October 13, 2016 9:54 AM
>> *To:* Walter Stovall
>> *Cc:* geoserver-users@lists.sourceforge.net
>> *Subject:* Re: [Geoserver-users] WFS will not read the same date that it
>> stores
>>
>>
>>
>> The GeoTools/GeoServer data handler should use the timezone of the server
>> (so if that is set to GMT then you need to convert before sending). This
>> allows for servers where clients can be in multiple timezones and need to
>> agree a fixed timezone when communicating with the server.
>>
>>
>>
>> If you are the only user of the client/server then you should be able to
>> set the timezone on the server and client to the same one and it should all
>> just work (tm).
>>
>>
>>
>> Ian
>>
>>
>>
>> On 13 October 2016 at 14:33, Walter Stovall
>> wrote:
>>
>> Using GeoServer2.8 I’m having a very basic problem with WFS-T inserting a
>> feature that has date fields. When I do a GetFeature to retrieve the date
>> I inserted, I get a value that’s one-day prior to the date I inserted.
>> This appears to be related to the GeoTools xsDateTimeFormat class used to
>> read the incoming XML on my insert-request and the code’s assumption that
>> the incom
Re: [Geoserver-users] WFS will not read the same date that it stores
I am pretty sure that was me. But I'll check tomorrow.
Ian
On 13 Oct 2016 19:54, "Andrea Aime" wrote:
> Ian, going by memory and answering from my tablet... didn't someone
> contribute a patch to make
> dates timezone independent? With a system variable to set that?
>
> Cheers
> Andrea
>
> On Thu, Oct 13, 2016 at 8:22 PM, Ian Turton wrote:
>
>> That sounds like a regression to me, when I'm back at my desk, I'll dig
>> out the previous tests and check how that slipped in.
>>
>> Can you raise a bug in the meantime so I don't forget.
>>
>> Ian
>>
>> On 13 Oct 2016 16:28, "Walter Stovall" wrote:
>>
>>> Thanks for the advice. Unfortunately following that path does not work
>>> for me. I still end up with dates that are one-behind.
>>>
>>>
>>>
>>> This was discovered with a more complicated arrangement, but I have this
>>> problem in my simple test environment where my geoserver is deployed to a
>>> local tomcat 8 on my Windows workstation. This is a computer setup for
>>> Eastern Standard Daylight time (which is an offset of -05:00).
>>>
>>>
>>>
>>> I browse to my http://localhost:8080/geoserver/web webapp and run the
>>> Demo page where I paste in the WFS-T Insert request I showed earlier that
>>> inserts a date of 01/04/2016. Then I see a new row has showed up in my
>>> back-end Oracle table where geoserver is storing these features with the
>>> OracleNGDataStore. Selecting the date from that row, I get 01/03/2016. If
>>> I drill down by asking Oracle to show the time too I’ll get 03-jan-2016
>>> 19:00:00. So obviously “somebody” is applying the -05:00 offset by the
>>> time the data is given to the Oracle driver. fwiw the Oracle dbtimezone is
>>> -04:00 but that hardly matters because Oracle expects to be given the data
>>> in the “correct” timezone and just stores what you give it.
>>>
>>>
>>>
>>> I’ve already discovered by watching the geoserver log that Oracle is
>>> receiving the wrong value.
>>>
>>>
>>>
>>> To find out more I build an eclipse workspace that includes geoserver
>>> and geotools and attach to the running tomcat.
>>>
>>> So first I break in the debugger at SimpleFeatureImpl which is getting
>>> hit by the SAX parsing invoked by WfsXmlReader. The *values* object
>>> array there has a date of “2016-01-03” (which is the toString output of
>>> Gregorian$Date with a fastTime of 145186560). This is ultimately going
>>> to become Jan 3 19:00 stored in Oracle. So I know things are bad already.
>>>
>>>
>>>
>>> Backtracking to see where things went wrong I back all the way up to
>>> where the Jan 4 date is getting parsed out of the XML for my WFS-T insert
>>> request. I stop at XsDateTimeFormat.parseObject(String, ParsePosition,
>>> boolean) and in there I see where there’s an assumption that the timezone
>>> will ALWAYS be GMT…
>>>
>>>
>>>
>>> *if* (parseTime) {
>>>
>>> tz = TimeZone.*getTimeZone*(digits.toString());
>>>
>>> } *else* {
>>>
>>> // there's no meaning for timezone if not parsing time
>>>
>>> // http://en.wikipedia.org/wiki/ISO_8601
>>>
>>> tz = TimeZone.*getTimeZone*("GMT");
>>>
>>> }
>>>
>>> Calendar cal = Calendar.*getInstance*(tz);
>>>
>>>
>>>
>>> So regardless of environment variables etc. I know that at this stage my
>>> incoming date is always represented as Jan 4 2016 GMT. It would appear
>>> that later this gets represented as EDT (my timezone) and becomes Jan 3
>>> 19:00.
>>>
>>>
>>>
>>> So I patched my code just now to call TimeZone.getDefault() instead of
>>> using “GMT” specifically. Now what gets stored in my database is correct,
>>> Jan 4 00:00.
>>>
>>>
>>>
>>> As to whether this specifically is a fix and whether similar problems
>>> wait for me with datetime vs. just date, I’m unclear at this point.
>>>
>>>
>>>
>>> What are your thoughts about this? Do I have a way to make it work
>>> without a code change?
>>>
>>>
>>>
>>> Thanks for your help Ian!
>>>
>>>
>>>
>>> Regards Walter Stovall
>>>
>>>
>>>
>>> *From:* Ian Turton [mailto:ijtur...@gmail.com]
>>> *Sent:* Thursday, October 13, 2016 9:54 AM
>>> *To:* Walter Stovall
>>> *Cc:* geoserver-users@lists.sourceforge.net
>>> *Subject:* Re: [Geoserver-users] WFS will not read the same date that
>>> it stores
>>>
>>>
>>>
>>> The GeoTools/GeoServer data handler should use the timezone of the
>>> server (so if that is set to GMT then you need to convert before sending).
>>> This allows for servers where clients can be in multiple timezones and need
>>> to agree a fixed timezone when communicating with the server.
>>>
>>>
>>>
>>> If you are the only user of the client/server then you should be able to
>>> set the timezone on the server and client to the same one and it should all
>>> just work (tm).
>>>
>>>
>>>
>>> Ian
>>>
>>>
>>>
>>> On 13 October 2016 at 14:33, Walter Stovall
>>> wrote:
>>>
>>> Using GeoServer2.8 I’m having a very basic problem with WFS-T inserting
>>> a feature that has date fields. When I do a GetFeature to
[Geoserver-users] Unable to update 'cached' image mosaic image
Hi all I'm using Geoserver 2.9, and I'm wondering about how Geoserver caches the image mosaic images. My set up 1. in the Database, I use the field 'dataset_id' to uniquely identify the image, and the path to the image is also stored. 2. I try to view the image like this http://localhost:8082/geoserver//wms?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&FORMAT=image%2Fjpeg&TRANSPARENT=true&STYLES&LAYERS=&SRS=EPSG%3A4326&WIDTH=768&HEIGHT=384&bbox=-112.05,40.0,-110,41.0&CQL_FILTER=%20dataset_id%3D%2713033%27%20 My observation 1. First, I added an image. Everything was good, I could view it with no problem. 2. Next, I updated the image path in the Database to point to a different image, for the same dataset_id. 3. Then I tried to view the image, but I still got the old image, not the new one. I have tried - Turning off Geowebcache - Turning off Tile Caching for the Image Mosaic layer - Ensuring all the 'caching' properties are set to false in the Image Mosaic config files (datastore.properties, indexer.properties, .properties - Clearing my browser cache (as I was viewing the image via OpenLayers on a web browser) Restarting Geoserver does work, but we do not want to restart Geoserver. Any ideas/comments are welcome. Thanks eting -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Unable-to-update-cached-image-mosaic-image-tp5290626.html Sent from the GeoServer - User mailing list archive at Nabble.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] WFS GetCapabilities failures
yes indeed. i create H2 database tables, some w/ and others w/o a geometry column. after publishing the first geometry-less one as a layer, the WFS GetCapabilities calls for both 1.0.0 and 1.1.0 versions fail. you are also correct in pointing out the UI does not allow geometry-less layers. trying to view those (geomtry-less) layers the UI does not allow changing the panel b/c of missing BBOX info. the Layer Preview also does not work w/ those layers. i was planning today on adding a dummy geometry column --a point w/ 0 value coordinates-- to ensure that works around the issue. will report back if there's interest in finding out this stops the failing WFS calls. On Thu, 13 Oct 2016 19:38:02 +0200, Andrea Aime wrote: > So are you configuring geometryless layers via the REST interface? > The UI should not allow null bounding boxes even on geometryless > layers. > > Cheers > Andrea > > On Thu, Oct 13, 2016 at 6:45 PM, Raif S. Naffah > wrote: > > > i believe what i'm seeing is explained by > > > > https://osgeo-org.atlassian.net/browse/GEOS-7216 > > > > > > On Wed, 28 Sep 2016 12:32:57 +1000, Raif S. Naffah wrote: > > > > > hi all, > > > > > > working w/ GeoServer 2.8.5 i'm getting sporadic failures when > > > requesting WFS capabilities. the failures show up in the > > > geoserver.log as follows: > > > > > > 2016-09-28 12:02:18,843 INFO [org.geoserver.wfs] - > > > Request: getServiceInfo > > > 2016-09-28 12:02:18,844 INFO [org.geoserver.wfs] - > > > Request: getCapabilities > > > baseUrl = http://localhost:9100/geoserver/ > > > service = WFS > > > 2016-09-28 12:02:18,879 ERROR [org.geoserver.ows] - > > > java.io.IOException > > > at > > > org.geoserver.wfs.response.GetCapabilitiesResponse.write( > > GetCapabilitiesResponse.java:63) > > > at org.geoserver.ows.Dispatcher.response(Dispatcher.java:996) at > > > org.geoserver.ows.Dispatcher.handleRequestInternal(Dispatcher.java:279) > > > at > > > org.springframework.web.servlet.mvc.AbstractController.handleRequest( > > AbstractController.java:153) > > > at > > > org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter > > .handle(SimpleControllerHandlerAdapter.java:48) > > > at > > > org.springframework.web.servlet.DispatcherServlet. > > doDispatch(DispatcherServlet.java:923) > > > at > > > org.springframework.web.servlet.DispatcherServlet. > > doService(DispatcherServlet.java:852) > > > at > > > org.springframework.web.servlet.FrameworkServlet.processRequest( > > FrameworkServlet.java:882) > > > at > > > org.springframework.web.servlet.FrameworkServlet. > > doGet(FrameworkServlet.java:778) > > > at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) at > > > javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at > > > org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487) > > > at > > > org.mortbay.jetty.servlet.ServletHandler$CachedChain. > > doFilter(ServletHandler.java:1093) > > > at > > > org.geoserver.filters.ThreadLocalsCleanupFilter.doFilter( > > ThreadLocalsCleanupFilter.java:28) > > > at > > > org.mortbay.jetty.servlet.ServletHandler$CachedChain. > > doFilter(ServletHandler.java:1084) > > > at > > > org.geoserver.filters.SpringDelegatingFilter$Chain.doFilter( > > SpringDelegatingFilter.java:75) > > > at > > > org.geoserver.wms.animate.AnimatorFilter.doFilter( > > AnimatorFilter.java:71) > > > at > > > org.geoserver.filters.SpringDelegatingFilter$Chain.doFilter( > > SpringDelegatingFilter.java:71) > > > at > > > org.geoserver.filters.SpringDelegatingFilter.doFilter( > > SpringDelegatingFilter.java:46) > > > at > > > org.mortbay.jetty.servlet.ServletHandler$CachedChain. > > doFilter(ServletHandler.java:1084) > > > at > > > org.geoserver.platform.AdvancedDispatchFilter.doFilter( > > AdvancedDispatchFilter.java:50) > > > at > > > org.mortbay.jetty.servlet.ServletHandler$CachedChain. > > doFilter(ServletHandler.java:1084) > > > at > > > org.springframework.security.web.FilterChainProxy$ > > VirtualFilterChain.doFilter(FilterChainProxy.java:311) > > > at > > > org.geoserver.security.filter.GeoServerCompositeFilter$ > > NestedFilterChain.doFilter(GeoServerCompositeFilter.java:69) > > > at > > > org.springframework.security.web.access.intercept. > > FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:116) > > > at > > > org.springframework.security.web.access.intercept. > > FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:83) > > > at > > > org.geoserver.security.filter.GeoServerCompositeFilter$ > > NestedFilterChain.doFilter(GeoServerCompositeFilter.java:73) > > > at > > > org.geoserver.security.filter.GeoServerCompositeFilter.doFilter( > > GeoServerCompositeFilter.java:92) > > > at > > > org.springframework.security.web.FilterChainProxy$ > > VirtualFilterChain.doFilter(FilterChainProxy.java:323) > > > at > > > org.geoserver.security.filter.GeoServerCompositeFilt
