Re: [Geoserver-users] Access denied after creating multiple accounts using REST API

[Darell van der Voort]

Hello everyone,

An update on the issue. I am now experiencing the problem regularly, even
when adding a single account. The roles.xml keeps getting corrupted, mostly
the associations between role_id and username are lost. It only happens
when I access the roles.xml file, but it does seem random as to when it
gets corrupted or not. Therefore it is difficult for me to reproduce the
exact error. These are the steps I take:

1) GET roles.xml from: /geoserver/geofence/rest/roles
2) POST rolename to: /geoserver/geofence/rest/roles/role/ + rolename
3) POST association to: /geoserver/geofence/rest/roles/role/ + rolename +
/user/ + username

Geoserver log:

2018-02-12 09:38:00,268 INFO [security.xml] - Successful lock:
security/role/default/roles.xml.lock
2018-02-12 09:38:00,268 INFO [geoserver.security] - Start storing roles for
service named default
2018-02-12 09:38:00,389 INFO [geoserver.security] - Storing roles
successful for service named default
2018-02-12 09:38:00,389 INFO [geoserver.security] - Start reloading roles
for service named default
2018-02-12 09:38:02,842 INFO [geoserver.security] - Reloading roles
successful for service named default
2018-02-12 09:38:02,842 INFO [geoserver.security] - Adjusted last modified
for file: security/role/default/roles.xml
2018-02-12 09:38:03,520 INFO [security.xml] - Successful lock:
security/role/default/roles.xml.lock
2018-02-12 09:38:03,520 INFO [geoserver.security] - Start storing roles for
service named default
2018-02-12 09:38:03,638 INFO [geoserver.security] - Storing roles
successful for service named default
2018-02-12 09:38:03,639 INFO [geoserver.security] - Start reloading roles
for service named default
2018-02-12 09:38:05,886 INFO [geoserver.security] - Reloading roles
successful for service named default
2018-02-12 09:38:05,887 INFO [geoserver.security] - Adjusted last modified
for file: security/role/default/roles.xml
2018-02-12 09:38:06,157 INFO [geoserver.security] - Start reloading roles
for service named default
2018-02-12 09:38:08,526 INFO [geoserver.security] - Reloading roles
successful for service named default
2018-02-12 09:38:08,529 INFO [geoserver.security] - Adjusted last modified
for file: security/role/default/roles.xml
2018-02-12 09:38:08,534 INFO [geoserver.security] - Start reloading
user/groups for service named default
2018-02-12 09:38:09,613 INFO [geoserver.security] - Reloading user/groups
successful for service named default
2018-02-12 09:38:09,613 INFO [geoserver.security] - Adjusted last modified
for file: security/usergroup/default/users.xml

Looking at the log it leaves to believe it has something to do with the
.lock file. As our database keeps getting bigger, the problem arises more
often. I believe that writing the roles.xml takes a longer time if there
are more users/roles. The two POST requests are executed directly after
each other, therefore trying to access the roles.xml file before it is
completely written by the first POST request. Shouldn't the lock file
prohibit this kind of behavior? I am working on a solution that checks for
the .lock file before accessing and writing to roles.xml as I believe this
is the source of the error.

Kind regards,
Darell

On Wed, Jan 24, 2018 at 10:01 AM, Darell van der Voort <darell...@gmail.com>
wrote:

> Hello,
>
> Thank you for the thorough explanation Harleen, very helpful. It turned
> out that also our roles.xml was corrupted in production. It did keep most
> of the role_ids, however it removed nearly all of the role-user
> associations, including the admin. Hence the lock out. We ware able to
> restore most of the accounts by re-adding the associations. Also the
> Geofence data rules were missing for most of the workspaces/accounts.
>
> I believe the corrupt file occurs when doing to much I/O to the xml files.
> The first error before the 403 was a xml.etree.ElementTree.ParseError.
> After that, the roles.xml was mostly lost. I am able to reproduce the error
> on our staging environment by making a lot of API calls to add users and
> check the xml for existing users. A solution that worked for me is leaving
> enough time between the calls. Last night I've added 450+ users, roles and
> workspaces without any problems. There were however a few minutes between
> each user creation as there was a data processing and uploading step in
> between. I am now backing up the users.xml and roles.xml regularly, losing
> those account associations in production had a huge impact.
>
> Andrea, I hope to find some time to make a vanilla installation with some
> descriptions and the script.
>
> Thanks again for the great help!
> Kind regards,
> Darell
>
> On Wed, Jan 24, 2018 at 9:26 AM, Andrea Aime <andrea.a...@geo-solutions.it
> > wrote:
>
>> Hi all,
>> thanks for moving the discussion forward. Just to be clear, the only way
>> a developer may look into this
>> is that y

Re: [Geoserver-users] Access denied after creating multiple accounts using REST API

[Darell van der Voort]

>>our setup).
>>>   - List of files Under /tomcat/webapps/geoserver/data/security/
>>>   - config.xml (This contained our filter chains)
>>>  - rest.properties (we made a change here for access on a
>>>  specific role)
>>>  - /filter/{{our_authentication}}/config.xml
>>>  - /role/default/
>>>  - /config.xml (this has the change I mentioned, however, we
>>> changed it after deploy because we were using our deploy 
>>> package)
>>> - /roles.xml
>>> - (the roles.xsd gets generated after first start up)
>>>  - /usergroup/{{our_usergroup_name}}/ (this is a new one we
>>>  created that is not default.)
>>> - /config.xml
>>> - /users.xml
>>> - /users.xsd
>>>  4. Start Tomcat Service
>>>5. Wait For Tomcat to Start
>>>6. Add Data Rules
>>>   1. These are our data rules using Geofence REST.
>>>7. After this we go to the admin page and see we have control again.
>>>8. We also ran a test with our admin user, so this might have
>>>triggered the authentication cache. Mabe best to wait 10 minutes till 
>>> your
>>>cache refreshes before adding the users.
>>>9. Stop Tomcat Service
>>>10. Modify users.xml and roles.xml as mentioned in the last email.
>>>11. Start Tomcat Service
>>>12. Ran our Users script
>>>   1. Loop through all users
>>>  1. curl REST API to add user
>>>  2. curl REST API to associate user with role
>>>  3. sleep 1 second (Not sure if we need this. Just noticed
>>>  without it, it will chug and possibly run into a stack overflow 
>>> exception)
>>>
>>>
>>> And those my friend our the steps we took. Like I said we use ansible,
>>> so we never isolated what exactly caused it to unlock. Actually listing
>>> this out, I am wondering if it was the refresh of users.xml and roles.xml
>>> to a blank state.
>>>
>>> Hope that helps.
>>>
>>>
>>>
>>> On Tue, Jan 23, 2018 at 6:45 AM, Darell van der Voort <
>>> darell...@gmail.com> wrote:
>>>
>>>> Hello Harleen, Andrea,
>>>>
>>>> Thank you very much for the input! Harleen, your problem is exactly the
>>>> same as we are facing. I am also adding authentication with geofence and
>>>> pull the exisiting users from the users.xml file. Normally we only add just
>>>> a few users without any problems. But indeed with more than 200 users the
>>>> lockdown happens.
>>>>
>>>> I have just pushed a new Geoserver build to production and changed both
>>>> config files to checkInterval 0 and validating to false. However the
>>>> problem still persists. I have rebooted the instances and restarted all the
>>>> task definitions. What do you mean exactly with 'redeploy Geofence and
>>>> security settings including the users.xml and roles.xml'? We have those
>>>> settings on a shared mount so that each Geoserver instance uses the same
>>>> settings. What steps did you do to redeploy, without creating new user and
>>>> role xmls?
>>>>
>>>> Andrea, I do not thing it can be reproduced without Geofence in the
>>>> mix, as this is the only way to add users via the REST API. I can however
>>>> reproduce it with Geofence. Also thanks for the support link.
>>>>
>>>> Kind regards,
>>>> Darell
>>>>
>>>> On Tue, Jan 23, 2018 at 10:47 AM, Andrea Aime <
>>>> andrea.a...@geo-solutions.it> wrote:
>>>>
>>>>> Hi Darell and Harleen,
>>>>> it seems you're on to something. Wondering, can it be reproduced
>>>>> without GeoFence in the mix?
>>>>> It would be useful to have a script that reproduces the problem on a
>>>>> vanilla GeoServer installation, if that can be done
>>>>> please open a ticket with it at: https://osgeo-org.atlassia
>>>>> n.net/projects/GEOS/summary
>>>>>
>>>>> Darell, this list offers volountary support, which does not do
>>>>> "urgent" (well, not with guarantees at least, it can happen of course).
>>>>> If you're in a hurry I'd suggest you also check
>>>>> http://geoserver.org/support/
>>>>>
>>

Re: [Geoserver-users] Access denied after creating multiple accounts using REST API

[Darell van der Voort]

Hello Harleen, Andrea,

Thank you very much for the input! Harleen, your problem is exactly the
same as we are facing. I am also adding authentication with geofence and
pull the exisiting users from the users.xml file. Normally we only add just
a few users without any problems. But indeed with more than 200 users the
lockdown happens.

I have just pushed a new Geoserver build to production and changed both
config files to checkInterval 0 and validating to false. However the
problem still persists. I have rebooted the instances and restarted all the
task definitions. What do you mean exactly with 'redeploy Geofence and
security settings including the users.xml and roles.xml'? We have those
settings on a shared mount so that each Geoserver instance uses the same
settings. What steps did you do to redeploy, without creating new user and
role xmls?

Andrea, I do not thing it can be reproduced without Geofence in the mix, as
this is the only way to add users via the REST API. I can however reproduce
it with Geofence. Also thanks for the support link.

Kind regards,
Darell

On Tue, Jan 23, 2018 at 10:47 AM, Andrea Aime <andrea.a...@geo-solutions.it>
wrote:

> Hi Darell and Harleen,
> it seems you're on to something. Wondering, can it be reproduced without
> GeoFence in the mix?
> It would be useful to have a script that reproduces the problem on a
> vanilla GeoServer installation, if that can be done
> please open a ticket with it at: https://osgeo-org.
> atlassian.net/projects/GEOS/summary
>
> Darell, this list offers volountary support, which does not do "urgent"
> (well, not with guarantees at least, it can happen of course).
> If you're in a hurry I'd suggest you also check http://geoserver.org/
> support/
>
> Cheers
> Andrea
>
>
> On Tue, Jan 23, 2018 at 1:50 AM, Harleen Lappano <hlapp...@cssflorida.net>
> wrote:
>
>> Hey Darell,
>>
>> I'm not a expert on Geoserver. However, funny story is that I ran into
>> this same issue last Friday as we were pushing our changes to our
>> production.
>> We are using Geoserver 2.9.1 for our product. I don't remember the tomcat
>> version.
>>
>> If it wasn't for your email, we would have been still trying to trace
>> down all our changes and deltas we made for this push window, so I
>> appreciate that you posted this it helped us narrow down and push pass this
>> issue.
>>
>> We were adding authentication to our geoserver with geofence so we can
>> add users using the REST api. I did a similar script where I pulled our
>> existing users in our system to also add them to the geoserver's user list
>> using REST api. At some point in our process we had a total lock down on
>> our geoserver in production. So just to see I ran a script on our dev box
>> to add 200 random users to the geoserver and was able to reproduce what
>> happened in our production.
>>
>> This is what we did based on our observations of the problem and it
>> seemed to get pass this issue for now. We are still running tests this week
>> on our product, however, mabe it will help you get along as well.
>> We are thinking that there might be an issue in geoserver regarding the
>> users.xml or roles.xml. It seems like the 3 components that might be the
>> cause are 1. Authentication Cache that runs every 10 minutes, 2. Our curl
>> commands in our script that adds the user. and 3. The interval check for
>> modifications on the users.xml or roles.xml. (these are the names we chose,
>> but it is the xml that holds the user group service and the role server).
>>
>> In order for us to get back to an unlock state, I had to redeploy our
>> GeoFence and security settings including the users.xml and roles.xml. I'm
>> not sure what is in the set that causes the geoserver to unlock because we
>> didn't trace it down that far.
>> Then we went ahead and changed our config.xml for our user group and
>> roles has (two config files):
>> 0
>> false
>>
>> We weren't sure about validating, but we turned it off anyways. After
>> that and a restart, we were able to run our script to add the users without
>> any problems. I will add that in our script we added a second delay after
>> each add. I noticed in the original time we did our script we ran into a
>> stack overflow issue.
>>
>> After all this I think we are concluding that there might have been a
>> lock on the file resource when reading and writing. However, this is just a
>> hunch without further testing.
>> Hopefully someone on this mailing list knows exactly what is happening.
>>
>>
>>
>> On Mon, Jan 22, 2018 at 5:02 AM, Darell van der Voort <
>> d

[Geoserver-users] Access denied after creating multiple accounts using REST API

[Darell van der Voort]

Hello everybody,

I'm running Geoserver 2.11.2 on Java 1.8.0_144 32 bits on Amazon Linux
together with Tomcat 9. I have a very urgent problem.

I have a Python script that uses the REST API to automatically create
users, set read/write permissions and create workspaces. I have been using
this for the last months without any problems. However today I had to
create 450+ accounts and workspace so I wrote a loop to generate the
accounts. This went flawless till about account 137. After that I got a
access denied:

HTTP 403 status Forbidden
Access is denied
The server understood the request but refuses to authorize it.
Apache Tomcat/9.01

Also when I log into the web interface using the admin account I cannot
access anything. The data is however still served. This leads me to believe
it is some kind of protection from Geoserver against DDoS or brute force
attacks. I do not have another account with admin rights.
How do I re-enable access to the Geoserver? I already tried restarting the
server instance, but no luck.

Thanks!
Darell
--
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

Please make sure you read the following two resources before posting to this 
list:
- Earning your support instead of buying it, but Ian Turton: 
http://www.ianturton.com/talks/foss4g.html#/
- The GeoServer user list posting guidelines: 
http://geoserver.org/comm/userlist-guidelines.html

If you want to request a feature or an improvement, also see this: 
https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer


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

[Geoserver-users] Adding imagePyramid granules for time series in Postgresql db

[Darell van der Voort]

Hello everybody,

I'm running Geoserver 2.11.2 on Java 1.8.0_144 32 bits on Amazon Linux
together with Tomcat 9. The plugins I have installed are imagemosaic,
imagepyramid, GeowebCache (internal) and Geofence.

I have a question about updating the granules for an imagePyramid in a
Postgresql database. I can successfully publish an imagePyramid and publish
the granules for each zoom level in a Postgresql database. However I also
want to be able to add tiffs to each zoom level as a time series.

For imagemosaics this works by PUTing each file to:
'workspaces/workspacename/coveragestores/storename/external.imagemosaic'.
Using the filename as the payload:
'file:/geoserver_datadir/imagery/filename.tif'. However when I apply the
same method to an imagePyramid I get a 405 in return. I tried both
external.imagemosaic as external.imagepyramid.

Is there any known method to update imagePyramids the same way as can be
done with imagemosaics? I could always drop the tables and re-build the
pyramid granule tables after adding the new files, but this seems like
a cumbersome
solution.

Kind regards,
Darell
--
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

Please make sure you read the following two resources before posting to this 
list:
- Earning your support instead of buying it, but Ian Turton: 
http://www.ianturton.com/talks/foss4g.html#/
- The GeoServer user list posting guidelines: 
http://geoserver.org/comm/userlist-guidelines.html

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

Re: [Geoserver-users] ImagePyramid using Postgresql for granules

[Darell van der Voort]

)
at
org.geotools.gce.imagepyramid.ImagePyramidFormat.getReader(ImagePyramidFormat.java:249)
at
org.geotools.gce.imagepyramid.ImagePyramidFormat.getReader(ImagePyramidFormat.java:56)
at
org.geoserver.catalog.ResourcePool.getGridCoverageReader(ResourcePool.java:1511)
at
org.geoserver.catalog.ResourcePool.getGridCoverageReader(ResourcePool.java:1441)
at
org.geoserver.catalog.impl.CoverageStoreInfoImpl.getGridCoverageReader(CoverageStoreInfoImpl.java:59)
at sun.reflect.GeneratedMethodAccessor547.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.geoserver.catalog.impl.ModificationProxy.invoke(ModificationProxy.java:147)
at com.sun.proxy.$Proxy64.getGridCoverageReader(Unknown Source)
at
org.geoserver.web.data.layer.NewLayerPageProvider.getItemsInternal(NewLayerPageProvider.java:95)
... 137 more

However the folder structure does change to the level structure (e.g. 0, 1,
etc) but only one table is created (in this case the table for folder level
1) and the table name is not named after the TypeName variable, but after
the folder name ('1'). For the other folders no shapefile and no tables are
created. I also tried different combinations, e.g putting the TypeName in
datastore.properties with no success. I did not try the method proposed by
Peter yet (using a indexer.xml instead of properties). Please let me know
if i'm missing something.

Thank you.

Kind regards.
Darell

On Mon, Oct 2, 2017 at 12:34 PM, Daniele Romagnoli <
daniele.romagn...@geo-solutions.it> wrote:

> Hi Darell,
>
> On Mon, Oct 2, 2017 at 11:30 AM, Darell van der Voort <darell...@gmail.com
> > wrote:
>
>> Hello Daniele,
>>
>> Thank you for your input! I now use a schema per workspace, but creating
>> a schema per imagepyramid would indeed solve the problem of duplicate table
>> names. So do I understand correctly that there is no possibility to change
>> the table names?
>>
>
> Nope, you can do that, instead.
> You can specify the same "schema" name in all the level's
> datastore.properties but you should specify a different "TypeName" property
> in each indexer file. The specific ImageMosaic level will index granules in
> that "TypeName" table.
>
> Hope this helps.
> Regards,
> Daniele
>
>
>
>
>> For example to: schema.imagepyramid0, schema.imagepyramid1 etc. In which
>> schema is the unique workspace schema and imagepyramid is the name of the
>> layer. Thank you!
>>
>> Kind regards,
>> Darell
>>
>> On Mon, Oct 2, 2017 at 11:19 AM, Daniele Romagnoli <
>> daniele.romagn...@geo-solutions.it> wrote:
>>
>>> Hi Darell,
>>> as you said, the imagePyramid is basically a set of imageMosaics: an
>>> ImageMosaic for each pyramid level.
>>> Therefore, each level should have its own indexer and, optionally, a
>>> datastore.properties if you want to catalog the granules into a DB instead
>>> of default shapefile.
>>>
>>> When using DB instead of shapefile, you may want to use a single
>>> database (as an instance, "pyramid") and store each level granule's index
>>> into a different schema name. Therefore, the datastore.properties of each
>>> level should define a different schema name, as an instance:
>>>
>>> pyramid/0/datastore.properties contains a "schema=level0" property
>>> pyramid/1/datastore.properties contains a "schema=level1" property
>>> pyramid/2/datastore.properties contains a "schema=level2" property
>>>
>>> Note that you should create the schemas (with "CREATE SCHEMA levelx" sql
>>> statements) in advance on your DB, before configuring the imagePyramid
>>> store in GeoServer.
>>>
>>> Hope this helps.
>>> Regards,
>>> Daniele
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Oct 2, 2017 at 10:54 AM, Darell van der Voort <
>>> darell...@gmail.com> wrote:
>>>
>>>> Hi Peter,
>>>>
>>>> Thank you for the examples, very helpful! Using a indexer.xml indeed
>>>> seems like a better set-up. Have you ever tried this in combination with
>>>> the imagepyramid plugin? I know that the imagepyramid are basically just
>>>> imagemoasics per folder level. However as the folder structure is different
>>>> it causes some problems. My folder structure looks like:
>>>>
>>>> /geoserver/data/workspace//0/.tiffs
>>>> /geoserver/data/workspace//1/.tiffs
>>>> /geoserver/data/workspace//2/.tiffs
>>>> etc..
>>>>
>>>> Wh

Re: [Geoserver-users] ImagePyramid using Postgresql for granules

[Darell van der Voort]

Hello Daniele,

Thank you for your input! I now use a schema per workspace, but creating a
schema per imagepyramid would indeed solve the problem of duplicate table
names. So do I understand correctly that there is no possibility to change
the table names? For example to: schema.imagepyramid0, schema.imagepyramid1
etc. In which schema is the unique workspace schema and imagepyramid is the
name of the layer. Thank you!

Kind regards,
Darell

On Mon, Oct 2, 2017 at 11:19 AM, Daniele Romagnoli <
daniele.romagn...@geo-solutions.it> wrote:

> Hi Darell,
> as you said, the imagePyramid is basically a set of imageMosaics: an
> ImageMosaic for each pyramid level.
> Therefore, each level should have its own indexer and, optionally, a
> datastore.properties if you want to catalog the granules into a DB instead
> of default shapefile.
>
> When using DB instead of shapefile, you may want to use a single database
> (as an instance, "pyramid") and store each level granule's index into a
> different schema name. Therefore, the datastore.properties of each level
> should define a different schema name, as an instance:
>
> pyramid/0/datastore.properties contains a "schema=level0" property
> pyramid/1/datastore.properties contains a "schema=level1" property
> pyramid/2/datastore.properties contains a "schema=level2" property
>
> Note that you should create the schemas (with "CREATE SCHEMA levelx" sql
> statements) in advance on your DB, before configuring the imagePyramid
> store in GeoServer.
>
> Hope this helps.
> Regards,
> Daniele
>
>
>
>
>
> On Mon, Oct 2, 2017 at 10:54 AM, Darell van der Voort <darell...@gmail.com
> > wrote:
>
>> Hi Peter,
>>
>> Thank you for the examples, very helpful! Using a indexer.xml indeed
>> seems like a better set-up. Have you ever tried this in combination with
>> the imagepyramid plugin? I know that the imagepyramid are basically just
>> imagemoasics per folder level. However as the folder structure is different
>> it causes some problems. My folder structure looks like:
>>
>> /geoserver/data/workspace//0/.tiffs
>> /geoserver/data/workspace//1/.tiffs
>> /geoserver/data/workspace//2/.tiffs
>> etc..
>>
>> Where the numbers stand for the pyramid levels which are filled with
>> multiple tiffs, the indexer.properties and the foldername.properties. I put
>> tiffs from different dates in the same folder and use a unique date in the
>> filename. Should I put the indexer.xml and datastore.properties in each
>> pyramid directory? I can try it later this week and will let you know if it
>> works.
>>
>> Kind regards,
>> Darell
>>
>> On Fri, Sep 29, 2017 at 11:43 AM, Peter Kovac <
>> peter.ko...@microstep-mis.com> wrote:
>>
>>> I usually configure ImageMosaic for time-series plain GeoTIFF granules
>>> so my advice might not be 100% accurate but I hope it helps anyway.
>>>
>>> Firstly, your schema seems wrong to me: you have two types specified for
>>> ingestion - java.util.Date and a Double after that. Perhaps another
>>> attribute of double type is missing or the :Double part should be deleted.
>>>
>>> Otherwise, I recommend using indexer.xml instead of indexer.properties
>>> for configuration. In your case it might look like this:
>>>
>>> 
>>> 
>>>
>>>   
>>>  ingestion<
>>> /attribute>
>>>   
>>>
>>>
>>>   
>>> *the_geom:Polygon,location:String,ingestion:java
>>> .util.Date
>>>   
>>>
>>>
>>>   
>>>  your_coverage_name
>>>  
>>>  
>>> 
>>>  
>>>   
>>>
>>>
>>>   
>>>  
>>> regex=([0-9]{14}),format=MMddHHmmss,fullPath=true
>>>  TimestampFileNameExtractorSPI
>>>  ingestion
>>>   
>>>
>>>
>>> 
>>> 
>>> 
>>> >> value="/path/to/directory/to/be/indexed" />
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Usually my ImageMosaic folder structure is like this (
>>> /opt/geoserver_data is the GEOSERVER_DATA_DIR)
>>> * the indexer.xml and datastore.properties files are in a
>>> /opt/geoserver_data/data/
>>> * there is a subdirectory, usually with a date tree structure for
>>> sto

Re: [Geoserver-users] ImagePyramid using Postgresql for granules

[Darell van der Voort]

Hi Peter,

Thank you for the examples, very helpful! Using a indexer.xml indeed seems
like a better set-up. Have you ever tried this in combination with the
imagepyramid plugin? I know that the imagepyramid are basically just
imagemoasics per folder level. However as the folder structure is different
it causes some problems. My folder structure looks like:

/geoserver/data/workspace//0/.tiffs
/geoserver/data/workspace//1/.tiffs
/geoserver/data/workspace//2/.tiffs
etc..

Where the numbers stand for the pyramid levels which are filled with
multiple tiffs, the indexer.properties and the foldername.properties. I put
tiffs from different dates in the same folder and use a unique date in the
filename. Should I put the indexer.xml and datastore.properties in each
pyramid directory? I can try it later this week and will let you know if it
works.

Kind regards,
Darell

On Fri, Sep 29, 2017 at 11:43 AM, Peter Kovac <peter.ko...@microstep-mis.com
> wrote:

> I usually configure ImageMosaic for time-series plain GeoTIFF granules so
> my advice might not be 100% accurate but I hope it helps anyway.
>
> Firstly, your schema seems wrong to me: you have two types specified for
> ingestion - java.util.Date and a Double after that. Perhaps another
> attribute of double type is missing or the :Double part should be deleted.
>
> Otherwise, I recommend using indexer.xml instead of indexer.properties for
> configuration. In your case it might look like this:
>
> 
> 
>
>   
>  ingestion<
> /attribute>
>   
>
>
>   
> *the_geom:Polygon,location:String,ingestion:
> java.util.Date
>   
>
>
>   
>  your_coverage_name
>  
>  
> 
>  
>   
>
>
>   
>  
> regex=([0-9]{14}),format=MMddHHmmss,fullPath=true
>  TimestampFileNameExtractorSPI
>  ingestion
>   
>
>
> 
> 
> 
>  value="/path/to/directory/to/be/indexed"
> />
> 
> 
> 
> 
> 
> Usually my ImageMosaic folder structure is like this (/opt/geoserver_data
> is the GEOSERVER_DATA_DIR)
> * the indexer.xml and datastore.properties files are in a
> /opt/geoserver_data/data/
> * there is a subdirectory, usually with a date tree structure for storing
> granules from separate days in separate directories:
> /opt/geoserver_data/data//tiff/
> /MM/DD/some_file_MMDDHHmss.tiff
> * in indexer.xml I have *Recursive *parameter set to
> *true ** I usually use absolute path to the tiff directory as
> *IndexingDirectories* parameter value, e.g. /opt/geoserver_data/data/<
> IMAGEMOSAIC_DIRECTORY>/tiff
>
> Finally, if I encounter any problems during ImageMosaic creation I ensure
> to:
> * set GeoServer logging to VERBOSE
> * drop any database table created (ImageMosaic will refuse to create store
> if a table with the same name already exists), along with index and
> metadata (if using Oracle)
> * try it again and look into the log (usually the problem is not revealed
> in the last stacktrace in the log, but in some before last)
> * if it doesn't help or I still cannot figure out what is wrong I launch
> Eclipse debugger and examine what EXACTLY is wrong (I used it a lot until I
> figured out how to properly configure time parsing regexes)
>
> Regards,
>
> Peter Kovac
>
>
>
> On 29. 9. 2017 10:40, Darell van der Voort wrote:
>
> Hi Peter,
>
> This is my indexer.properties configuration:
>
> Caching=false
> TimeAttribute=ingestion
> Schema=*the_geom:Polygon,location:String,ingestion:java.util.Date:Double
> PropertyCollectors=TimestampFileNameExtractorSPI[timeregex](ingestion)
>
> And this is my 0.properties which is automatically generated for the
> lowest zoomlevel (0):
>
> #-Automagically created from GeoTools-
> #Wed Sep 27 14:50:18 UTC 2017
> MosaicCRS=EPSG\:32617
> Levels=0.062,0.062
> Heterogeneous=false
> TimeAttribute=ingestion
> AbsolutePath=false
> Name=0
> TypeName=0
> Caching=false
> ExpandToRGB=false
> LocationAttribute=location
> SuggestedSPI=it.geosolutions.imageioimpl.plugins.tiff.TIFFImageReaderSpi
> CheckAuxiliaryMetadata=false
> LevelsNum=1
>
> So like I said, the plugin automatically configures level 0 to the
> PostgreSQL DB if I add the datastore.properties files, but refuses to do so
> for other levels if I add the datastore.properties file to the folder
> levels. If I do not add the datastore.properties file to the additional
> levels, the plugin automatically creates a shapefile for these levels,
> while using the DB connection for level 0. This combination works, even
> wi

Re: [Geoserver-users] GWC tiles Seeding fails with error: Problem communicating with GeoServer ServiceException Could not find layer

[Darell van der Voort]

Hi Steve,

Are the layers protected? Do you use the GeoFence plugin?

Kind regards,
Darell

On Fri, Sep 29, 2017 at 11:05 AM, steve.omondi 
wrote:

> Hi guys,
>
> I have a problem with Integrated GeowebCache.
> Seeding Layers fails and here is the stack trace.
>
> I have tried Vector and Raster layers a like. If it's important I have
> changed the GEOWEBCACHE_CACHE_DIR=/serverDir/ externalized.
>
> I have tried to have the raster style from the defaul Global workspace to
> same workspace as Layer and nothing works.
>
> Opening the Layer Preview through the GWC and WMS endpoint and zooming
> around actually creates the tiles.
> Seeding fails.
>
>
>
> Prior to this Exception I have the following in the  logs.
>
> 2017-09-29 11:41:09,759 INFO [org.geotools.referencing.factory] -
> *user_projections/epsg_operations.properties was not found*, using the
> default set of coordinate operation overrides (normally empty)
> 2017-09-29 11:41:09,760 INFO [org.geotools.referencing.factory] - Using
> "file:/opt/tomcat2/webapps/geoserver/WEB-INF/lib/gs-main-
> 2.11.2.jar!/org/vfny/geoserver/crs/epsg_operations.properties"
> as EPSG factory.
>
> and
>
> 2017-09-29 11:41:37,242 DEBUG [org.geotools.referencing.factory] - Failure
> in the primary factory: No code "EPSG:900913" from authority "European
> Petroleum Survey Group" found for object of type "IdentifiedObject". Now
> trying the fallback factory...
> 2017-09-29 11:41:37,249 DEBUG [org.geotools.referencing.factory] - Failure
> in the primary factory: No code "EPSG:900913" from authority "European
> Petroleum Survey Group" found for object of type
> "CoordinateReferenceSystem". Now trying the fallback factory...
>
>
> This issue is killing me. Kindly assist.
>
>
>
>
>
> -
> Kind Regards,
>
> Steve Omondi
> GIS & DB Developer/DBA
> Ramani Online, Ramani Geosystems
> --
> Sent from: http://osgeo-org.1560.x6.nabble.com/GeoServer-User-
> f3786390.html
>
> 
> --
> 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
>
> Please make sure you read the following two resources before posting to
> this list:
> - Earning your support instead of buying it, but Ian Turton:
> http://www.ianturton.com/talks/foss4g.html#/
> - The GeoServer user list posting guidelines: http://geoserver.org/comm/
> userlist-guidelines.html
>
> 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

Please make sure you read the following two resources before posting to this 
list:
- Earning your support instead of buying it, but Ian Turton: 
http://www.ianturton.com/talks/foss4g.html#/
- The GeoServer user list posting guidelines: 
http://geoserver.org/comm/userlist-guidelines.html

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

Re: [Geoserver-users] ImagePyramid using Postgresql for granules

[Darell van der Voort]

Hi Peter,

This is my indexer.properties configuration:

Caching=false
TimeAttribute=ingestion
Schema=*the_geom:Polygon,location:String,ingestion:java.util.Date:Double
PropertyCollectors=TimestampFileNameExtractorSPI[timeregex](ingestion)

And this is my 0.properties which is automatically generated for the lowest
zoomlevel (0):

#-Automagically created from GeoTools-
#Wed Sep 27 14:50:18 UTC 2017
MosaicCRS=EPSG\:32617
Levels=0.062,0.062
Heterogeneous=false
TimeAttribute=ingestion
AbsolutePath=false
Name=0
TypeName=0
Caching=false
ExpandToRGB=false
LocationAttribute=location
SuggestedSPI=it.geosolutions.imageioimpl.plugins.tiff.TIFFImageReaderSpi
CheckAuxiliaryMetadata=false
LevelsNum=1

So like I said, the plugin automatically configures level 0 to the
PostgreSQL DB if I add the datastore.properties files, but refuses to do so
for other levels if I add the datastore.properties file to the folder
levels. If I do not add the datastore.properties file to the additional
levels, the plugin automatically creates a shapefile for these levels,
while using the DB connection for level 0. This combination works, even
with a time dimension. However I would like to use the DB connection for
all levels and use unique table names in the DB.

Kind regards,
Darell




On Fri, Sep 29, 2017 at 9:59 AM, Peter Kovac <peter.ko...@microstep-mis.com>
wrote:

> Hi Darell,
>
> can you post your indexer.xml configuration for the imagemosaic?
>
> Regards,
>
> Peter Kovac
>
> On 28. 9. 2017 9:59, Darell van der Voort wrote:
>
> Hello everybody,
>
> I'm running Geoserver 2.11.2 on Java 1.8.0_144 32 bits on Amazon Linux
> together with Tomcat 9. The plugins I have installed are imagemosaic,
> imagepyramid, GeowebCache (internal) and Geofence.
>
> When using the imagemosaic plugin I am able to use a Postgresql DB for
> storing the granules and time dimension via a datastore.properties file.
> The file looks like:
>
> SPI=org.geotools.data.postgis.PostgisNGJNDIDataStoreFactory
> schema=database_schema_name
> Loose\ bbox=true
> Estimated\ extends=false
> validate\ connections=true
> Connection\ timeout=10
> preparedStatements=true
> jndiReferenceName=java:comp/env/jdbc/postgis
>
> Which work as expected. However when I add the same file in the
> imagepyramid datastructure, this setup fails. When I add this
> datastore.properties in just the lowest level (0) then that level gets
> configured in a database table, while the higher levels are configured
> using a shapefile. When I add a datastore.properties to all levels,
> geoserver returns the following error:
>
> 2017-09-28 07:39:40,780 ERROR [gce.imagemosaic] -
> java.io.IOException
> at org.geotools.gce.imagemosaic.ImageMosaicConfigHandler.
> createGranuleCatalogFromDatastore(ImageMosaicConfigHandler.java:406)
> at org.geotools.gce.imagemosaic.ImageMosaicConfigHandler.createCatalog(
> ImageMosaicConfigHandler.java:329)
> at org.geotools.gce.imagemosaic.ImageMosaicConfigHandler.buildCatalog(
> ImageMosaicConfigHandler.java:962)
> at org.geotools.gce.imagemosaic.ImageMosaicConfigHandler.indexingPreamble(
> ImageMosaicConfigHandler.java:941)
> at org.geotools.gce.imagemosaic.ImageMosaicDirectoryWalker$
> MosaicDirectoryWalker.(ImageMosaicDirectoryWalker.java:109)
> at org.geotools.gce.imagemosaic.ImageMosaicDirectoryWalker.run(
> ImageMosaicDirectoryWalker.java:197)
> at org.geotools.gce.imagemosaic.Utils.createMosaic(Utils.java:460)
> at org.geotools.gce.imagemosaic.Utils.checkSource(Utils.java:1336)
> at org.geotools.gce.imagemosaic.ImageMosaicReader.initReaderFromURL(
> ImageMosaicReader.java:532)
> at org.geotools.gce.imagemosaic.ImageMosaicReader.(
> ImageMosaicReader.java:479)
> at org.geotools.gce.imagemosaic.ImageMosaicFormat.getReader(
> ImageMosaicFormat.java:504)
> at org.geotools.gce.imagepyramid.Utils.checkSource(Utils.java:200)
> at org.geotools.gce.imagepyramid.ImagePyramidReader.(
> ImagePyramidReader.java:177)
> at org.geotools.gce.imagepyramid.ImagePyramidFormat.getReader(
> ImagePyramidFormat.java:249)
> at org.geotools.gce.imagepyramid.ImagePyramidFormat.getReader(
> ImagePyramidFormat.java:56)
> at org.geoserver.catalog.ResourcePool.getGridCoverageReader(
> ResourcePool.java:1511)
> at org.geoserver.catalog.ResourcePool.getGridCoverageReader(
> ResourcePool.java:1441)
> at org.geoserver.catalog.impl.CoverageStoreInfoImpl.getGridCoverageReader(
> CoverageStoreInfoImpl.java:59)
> .
> at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(
> TaskThread.java:61)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.NullPointerException
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:264)
> at org.geotools.gce.imagemosaic.ImageMosaicConfigHandler.
> createGranuleCatalog

Re: [Geoserver-users] GWC tiles Seeding fails with error: Problem communicating with GeoServer ServiceException Could not find layer

[Darell van der Voort]

Ok. I faced the exact same problem, however I am using Geofence on top of
the Geoserver security system. So maybe my solution does not work, but this
is how I fixed it;

First make sure that there are separate read and write data rules for the
workspace in data security:

workspace.*.r
workspace.*w

and make sure the admin has acces to these rules.

Next set a Geofence data rule that allows every users to every layer of
that workspace. This is a temporarily rule, which is only needed for
seeding. If this rule is not applied, seeding does not work as the layer is
still protected. After seeding you can remove the rule and the layer will
be protected. The internal data rules should remain set.

Hope this helps. I can recommend the Geofence plug-in as this gives you
much more control over data security.

Kind regards,
Darell

On Fri, Sep 29, 2017 at 12:02 PM, Steve Omondi <steve.omo...@ramani.co.ke>
wrote:

> No. I don't use Geofence module. However, I have some Data security rules
> yes using the Geoserver Data Securty Subsystem.
>
> I'm seeding while logged in with the admin user.
>
> Kind regards,
> Steve Omondi
>
> On Fri, Sep 29, 2017 at 1:00 PM, Darell van der Voort <darell...@gmail.com
> > wrote:
>
>> Hi Steve,
>>
>> Are the layers protected? Do you use the GeoFence plugin?
>>
>> Kind regards,
>> Darell
>>
>> On Fri, Sep 29, 2017 at 11:05 AM, steve.omondi <steve.omo...@ramani.co.ke
>> > wrote:
>>
>>> Hi guys,
>>>
>>> I have a problem with Integrated GeowebCache.
>>> Seeding Layers fails and here is the stack trace.
>>>
>>> I have tried Vector and Raster layers a like. If it's important I have
>>> changed the GEOWEBCACHE_CACHE_DIR=/serverDir/ externalized.
>>>
>>> I have tried to have the raster style from the defaul Global workspace to
>>> same workspace as Layer and nothing works.
>>>
>>> Opening the Layer Preview through the GWC and WMS endpoint and zooming
>>> around actually creates the tiles.
>>> Seeding fails.
>>>
>>>
>>>
>>> Prior to this Exception I have the following in the  logs.
>>>
>>> 2017-09-29 11:41:09,759 INFO [org.geotools.referencing.factory] -
>>> *user_projections/epsg_operations.properties was not found*, using the
>>> default set of coordinate operation overrides (normally empty)
>>> 2017-09-29 11:41:09,760 INFO [org.geotools.referencing.factory] - Using
>>> "file:/opt/tomcat2/webapps/geoserver/WEB-INF/lib/gs-main-2.1
>>> 1.2.jar!/org/vfny/geoserver/crs/epsg_operations.properties"
>>> as EPSG factory.
>>>
>>> and
>>>
>>> 2017-09-29 11:41:37,242 DEBUG [org.geotools.referencing.factory] -
>>> Failure
>>> in the primary factory: No code "EPSG:900913" from authority "European
>>> Petroleum Survey Group" found for object of type "IdentifiedObject". Now
>>> trying the fallback factory...
>>> 2017-09-29 11:41:37,249 DEBUG [org.geotools.referencing.factory] -
>>> Failure
>>> in the primary factory: No code "EPSG:900913" from authority "European
>>> Petroleum Survey Group" found for object of type
>>> "CoordinateReferenceSystem". Now trying the fallback factory...
>>>
>>>
>>> This issue is killing me. Kindly assist.
>>>
>>>
>>>
>>>
>>>
>>> -
>>> Kind Regards,
>>>
>>> Steve Omondi
>>> GIS & DB Developer/DBA
>>> Ramani Online, Ramani Geosystems
>>> --
>>> Sent from: http://osgeo-org.1560.x6.nabble.com/GeoServer-User-f3786390.
>>> html
>>>
>>> 
>>> --
>>> 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
>>>
>>> Please make sure you read the following two resources before posting to
>>> this list:
>>> - Earning your support instead of buying it, but Ian Turton:
>>> http://www.ianturton.com/talks/foss4g.html#/
>>> - The GeoServer user list posting guidelines:
>>> http://geoserver.org/comm/userlist-guidelines.html
>>>
>>> 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

Please make sure you read the following two resources before posting to this 
list:
- Earning your support instead of buying it, but Ian Turton: 
http://www.ianturton.com/talks/foss4g.html#/
- The GeoServer user list posting guidelines: 
http://geoserver.org/comm/userlist-guidelines.html

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

[Geoserver-users] ImagePyramid using Postgresql for granules

[Darell van der Voort]

Hello everybody,

I'm running Geoserver 2.11.2 on Java 1.8.0_144 32 bits on Amazon Linux
together with Tomcat 9. The plugins I have installed are imagemosaic,
imagepyramid, GeowebCache (internal) and Geofence.

When using the imagemosaic plugin I am able to use a Postgresql DB for
storing the granules and time dimension via a datastore.properties file.
The file looks like:

SPI=org.geotools.data.postgis.PostgisNGJNDIDataStoreFactory
schema=database_schema_name
Loose\ bbox=true
Estimated\ extends=false
validate\ connections=true
Connection\ timeout=10
preparedStatements=true
jndiReferenceName=java:comp/env/jdbc/postgis

Which work as expected. However when I add the same file in the
imagepyramid datastructure, this setup fails. When I add this
datastore.properties in just the lowest level (0) then that level gets
configured in a database table, while the higher levels are configured
using a shapefile. When I add a datastore.properties to all levels,
geoserver returns the following error:

2017-09-28 07:39:40,780 ERROR [gce.imagemosaic] -
java.io.IOException
at
org.geotools.gce.imagemosaic.ImageMosaicConfigHandler.createGranuleCatalogFromDatastore(ImageMosaicConfigHandler.java:406)
at
org.geotools.gce.imagemosaic.ImageMosaicConfigHandler.createCatalog(ImageMosaicConfigHandler.java:329)
at
org.geotools.gce.imagemosaic.ImageMosaicConfigHandler.buildCatalog(ImageMosaicConfigHandler.java:962)
at
org.geotools.gce.imagemosaic.ImageMosaicConfigHandler.indexingPreamble(ImageMosaicConfigHandler.java:941)
at
org.geotools.gce.imagemosaic.ImageMosaicDirectoryWalker$MosaicDirectoryWalker.(ImageMosaicDirectoryWalker.java:109)
at
org.geotools.gce.imagemosaic.ImageMosaicDirectoryWalker.run(ImageMosaicDirectoryWalker.java:197)
at org.geotools.gce.imagemosaic.Utils.createMosaic(Utils.java:460)
at org.geotools.gce.imagemosaic.Utils.checkSource(Utils.java:1336)
at
org.geotools.gce.imagemosaic.ImageMosaicReader.initReaderFromURL(ImageMosaicReader.java:532)
at
org.geotools.gce.imagemosaic.ImageMosaicReader.(ImageMosaicReader.java:479)
at
org.geotools.gce.imagemosaic.ImageMosaicFormat.getReader(ImageMosaicFormat.java:504)
at org.geotools.gce.imagepyramid.Utils.checkSource(Utils.java:200)
at
org.geotools.gce.imagepyramid.ImagePyramidReader.(ImagePyramidReader.java:177)
at
org.geotools.gce.imagepyramid.ImagePyramidFormat.getReader(ImagePyramidFormat.java:249)
at
org.geotools.gce.imagepyramid.ImagePyramidFormat.getReader(ImagePyramidFormat.java:56)
at
org.geoserver.catalog.ResourcePool.getGridCoverageReader(ResourcePool.java:1511)
at
org.geoserver.catalog.ResourcePool.getGridCoverageReader(ResourcePool.java:1441)
at
org.geoserver.catalog.impl.CoverageStoreInfoImpl.getGridCoverageReader(CoverageStoreInfoImpl.java:59)
.
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.NullPointerException
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:264)
at
org.geotools.gce.imagemosaic.ImageMosaicConfigHandler.createGranuleCatalogFromDatastore(ImageMosaicConfigHandler.java:389)
... 160 more

Is it possible to configure the granules of all levels in the database? And
if so, how would my datastore.properties file look like? Like I said, it
works fine for the lowest level (0) but it fails for all the levels above.
If it may not be possible, is it sufficient to use the shapefiles as an
index for the granules? The geoserver is used in a production environment
and I am worried about performance issues when using the shapefiles as
index.

Furthermore the imagepyramid automatically names the table after the level
folder (0). This folder and table name are automatically created when
configuring the datastore. Is there a way to custom name the folder and
thus the table name? Otherwise I could end up with multiple '0' tables in
the same schema.

Many thanks!

Kind regards,
Darell
--
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

Please make sure you read the following two resources before posting to this 
list:
- Earning your support instead of buying it, but Ian Turton: 
http://www.ianturton.com/talks/foss4g.html#/
- The GeoServer user list posting guidelines: 
http://geoserver.org/comm/userlist-guidelines.html

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

[Geoserver-users] Seeding of imagemosaic layer problem

[Darell van der Voort]

Hello everybody,

I'm running Geoserver 2.11.2 on Java 1.8.0_144 32 bits on Amazon Linux
together with Tomcat 9. The plugins I have installed are imagemosaic,
imagepyramid, GeowebCache (internal) and Geofence.

Raster datasources are configured via the imagemosaic plugin and uses the
JNDI connection pooling. Granules are stored in a PostgreSQL database. All
raster granules have a time dimension.

When I start seeding a layer which only contains a single tiff in the
imagemosaic, seeding works fine and all tiles are created at the selected
zoomlevels. However when I apply the same method to an imagemosiac that
contains multiple tiffs, only tiles until zoomlevel 6 are generated. After
that the seeding stops with the following error:

2017-09-26 09:22:26,133 INFO [seed.GWCTask] - Thread group finished SEED
> task after 1.919 seconds
> 2017-09-26 09:22:26,133 ERROR [seed.MTSeeder] - Problem communicating with
> GeoServer
> org.geowebcache.GeoWebCacheException: Problem communicating with GeoServer
> at
> org.geoserver.gwc.layer.GeoServerTileLayer.getMetatilingReponse(GeoServerTileLayer.java:611)
> at
> org.geoserver.gwc.layer.GeoServerTileLayer.seedTile(GeoServerTileLayer.java:800)
> at org.geowebcache.seed.SeedTask.doActionInternal(SeedTask.java:141)
> at org.geowebcache.seed.GWCTask.doAction(GWCTask.java:76)
> at org.geowebcache.seed.MTSeeder.call(MTSeeder.java:36)
> at org.geowebcache.seed.MTSeeder.call(MTSeeder.java:25)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.NullPointerException
> at javax.media.jai.PlanarImage.copyData(PlanarImage.java:2344)
> at javax.media.jai.RenderedOp.copyData(RenderedOp.java:2299)
> at
> org.geoserver.gwc.layer.GeoServerMetaTile.createTile(GeoServerMetaTile.java:194)
> at
> org.geoserver.gwc.layer.GeoServerMetaTile.writeTileToStream(GeoServerMetaTile.java:100)
> at org.geowebcache.layer.TileLayer.saveTiles(TileLayer.java:679)
> at
> org.geoserver.gwc.layer.GeoServerTileLayer.getMetatilingReponse(GeoServerTileLayer.java:608)
> ... 9 more



Is the imagemosaic plugin with multiple tiffs not compatible with
GeowebCache seeding?

I have also tried the imagepyramid plugin using the data format as
generated with gdal_retile. Seeding then also works for multiple tiffs.
However with the imagepyramid plugin I do not seem to be able to use a DB
for storing the granules or add a time dimension (which is essential). Is
this true or am I missing something?

Thank you for your help.

Kind regards,
Darell
--
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

Please make sure you read the following two resources before posting to this 
list:
- Earning your support instead of buying it, but Ian Turton: 
http://www.ianturton.com/talks/foss4g.html#/
- The GeoServer user list posting guidelines: 
http://geoserver.org/comm/userlist-guidelines.html

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