Hi Tobias,
I don't know off the top of my head, but you can always make a second curl
call in PUT mode
to force the desired handling
Cheers
Andrea
On Fri, Jul 22, 2016 at 10:28 AM, Tobias Reinicke
wrote:
> Thanks Andrea,
> Yes it was on "leave native". Changing that to "force declared" (and
>
Thanks Andrea,
Yes it was on "leave native". Changing that to "force declared" (and
undoing the tomcat java option) also solves the problem.
Do you happen to know how to specify "force declared" on a shapefile when
loading it via curl?
Thanks,
Toby
On 20 July 2016 at 16:23, Andrea Aime wrote:
On Wed, Jul 20, 2016 at 4:17 PM, Diego Nieto Cid wrote:
> The issue is marked as fixed so I'm not sure why it was happening. May
> it's something that must be fixed per projection.
>
Not really. The fix just tries to leverage an eventual EPSG code baked into
the projection, but it won't work for
Yes, very good. That has solved that performance problem.
My projection is EPSG:27700 which is most definitely part of the official
EPSG database, so unsure if that fix has helped much.
Anyway, option added and all working fine.
Thanks for your help,
Toby
On 20 July 2016 at 15:17, Diego Nieto C
Hi
> El 20 jul 2016, a las 06:57, Tobias Reinicke escribió:
> 4. A shapefile store and info_format application/json = ~ 3000ms !
>
Yes I've seen that performance issue with a Shapefile in the Sinusoidal
projection.
I've found this related issue
https://osgeo-org.atlassian.net/browse/GEOS
Hello All,
I am seeing something that I'm not sure about.
A GFI request to a layer through Geoserver with:
1. A postgres store and info_format text/html = ~50ms.
2. A postgres store and info_format application/json = ~45ms
3. A shapefile store and info_format text/html = ~30ms
4. A shapefile stor
