I have not used an external upload with GeoTIFFs recently. However, I work
with and on the RESTConfig API quite regularly.
The external.tiff notation cues GeoServer to accept a path to a file, which
it then loads directly. ("External" as in, you uploaded the file already
through a mechanism external to GeoServer.)
--data-binary @/path/to/file cues curl to send the content of a file as the
body of the request.
So, this request:
> curl -v -u admin:geoserver -XPUT --data-binary
> @/media/data/images/SPOT5/S090829143259765/SCENE01/IMAGERY.TIF
> http://192.168.241.24:54900/geoserver/rest/workspaces/storm-workspace/coveragestores/test/external.geotiff
Sends an entire GeoTIFF and instructs GeoServer to treat it as a filename
(which means loading it into a single string, among other things). The heap
space error is not surprising after that.
However, I believe this command is getting close. Try using:
--data-ascii=/media/data/images/SPOT5/S090829143259765/SCENE01/IMAGERY.TIF
instead of the data-binary you were passing before.
Hope this helps.
--
David Winslow
OpenGeo - http://opengeo.org/
On Tue, Aug 31, 2010 at 10:13 AM, Cyril Gallay <cg....@ntropic.fr> wrote:
> Hello,
>
> I tried to use external.tiff, external.geotiff, url.tiff, url.geotiff, used
> -XPUT or -XPOST method. I also tried with --data-ascii instead of
> --data-binary, but it did not work either. Here are some lines i tried :
>
> curl -u admin:geoserver -POST --data-ascii
> @/media/data/images/SPOT5/S090829143259765/SCENE01/IMAGERY.TIF
> http://192.168.241.24:54900/geoserver/rest/workspaces/storm-workspace/coveragestores/test/external.tiff
> => i get 'Unsupported format: tiff% '
> In fact, each time i tried with the .tiff extension i got the 'Unsupported
> format' message
>
> curl -u admin:geoserver -XPOST --data-binary
> @/media/data/images/SPOT5/S090829143259765/SCENE01/IMAGERY.TIF
> http://192.168.241.24:54900/geoserver/rest/workspaces/storm-workspace/coveragestores/test/external.geotiff
> => I get a 'method not allowed' message
>
> curl -v -u admin:geoserver -XPUT --data-binary
> @/media/data/images/SPOT5/S090829143259765/SCENE01/IMAGERY.TIF
> http://192.168.241.24:54900/geoserver/rest/workspaces/storm-workspace/coveragestores/test/external.geotiff
> => with this one i get a 'Java Heap Space error'
>
> Have you ever succesfully done this kind of insertion in GeoServer ?
>
> Thanks for your help
>
>
>
>
>
> On 08/27/2010 10:28 AM, David Winslow wrote:
>
> I think there's a gap in the documentation here, but it is possible.
> Just POST the path to the file to
> rest/workspaces/ws/coveragestores/cs/external.tiff
>
> curl --data-ascii="/path/to/coverage.tiff" \
>
> http://$GS/rest/workspaces/topp/coveragestores/newstore/external.tiff
>
>
> There is also url.tiff to fetch from some (possibly remote) URL.
>
> Hope this helps.
>
> --
> David Winslow
> OpenGeo - http://opengeo.org/
>
> On Fri, Aug 27, 2010 at 8:53 AM, Cyril Gallay <cg....@ntropic.fr> wrote:
>
>> Hi everybody,
>>
>> I'm using Curl for a while now to upload Geotiff files to GeoServer but
>> i am stuck with one problem : each time i want to upload a big file
>> (around 1Go or more), i get an error like the following :
>>
>> curl: option --data-binary: out of memory
>>
>> I get this error is coming from Curl which means i will not be able to
>> upload this files with the rest plugin.
>> But i keep thinking that there might be something else to do. For
>> example, if i could just write the image at the right location on the
>> disk (lets say in the geoserver data directory), would i be able to use
>> Curl just to ask geoserver to generate the coverage store ?
>>
>> I've already tried to put the image in the right place and use the same
>> command i use to upload image into geoserver but it looks like the image
>> is being uploaded ... on itself. Could not Geoserver just create the
>> coverage store without uploading the image that is already there ?
>>
>> Thanks for your answers
>>
>> Cyril
>>
>>
>> ------------------------------------------------------------------------------
>> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
>> Be part of this innovative community and reach millions of netbook users
>> worldwide. Take advantage of special opportunities to increase revenue and
>> speed time-to-market. Join now, and jumpstart your future.
>> http://p.sf.net/sfu/intel-atom-d2d
>> _______________________________________________
>> Geoserver-users mailing list
>> Geoserver-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>>
>
>
>
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
