On Wed, Feb 2, 2011 at 8:02 PM, Mike Pumphrey <m...@opengeo.org> wrote:
> Thanks for the notes, Andrea, this is super helpful.  Follow-ups, below.
>
>> all keys are case insenstive, all values are case sensitive.
>
> Okay, but I do see that service=WPS works as well as service=wps.  Just 
> GeoServer being nice, though, I guess.

Yep, that's my understanding as well.

>> - the buffer in the example returns a square... correct answer given the 
>> params, but a little
>>    outside what one would expect from a buffer operation
>
> I was looking for an example that would be simple to understand from just 
> looking at the coordinates.  If I had created a circle (or polygon 
> equivalent), it might be more real world, but the numbers might not be so 
> understandable.  But I could change the example, though, if you thought it 
> valuable.  It was just the first process I came up with.

Yeah, a circle would be made of a lot of coordinates. No biggie.

> Also, found it interesting that as is, the values were like -10.00000000067 
> instead of -10.0.  :)
>
>> - in the geoserver processes paragraph you say "These functions have the 
>> added bonus
>>    of being able to operate on existing layers in GeoServer, and can even 
>> write the output
>>    to a new GeoServer layer".
>>    Actually any process can work against existing GS layers, it just
> ...
>
> Okay.  How should I categorize the differences between the gs: and the JTS: 
> processes?  (Or is there no important distinction?)  I saw that the request 
> builder had an extra entry for VECTOR_LAYER on the gs: processes, which is 
> why I made the note.

JTS processes are made to expose jts capabilities and work on single geomtries.
GS processes... are all over the place, they do pretty much everything now.
There is a number of them that is specific to GS though, such as gs:Import

VECTOR_LAYER is something every process consuming feature collection will
have.

>
>> - the trick GS uses to get data off the internal WFS/WCS is to use a special 
>> URL
>>    for the wfs/wcs server, http://geoserver/wfs and
>> http://geoserver/wcs (if memory
>>    serves me right) and that part is just a GS convention, it's not
>> anything that is
>>    part of the standard
>
> Okay, I'll make a note of that.
>
>> - that said GS can feed off any remote WFS/WCS just fine (provided the chosen
>>    output format can be parsed by GS), and in general, but any remote call
>>    whatsoever that returns something parseable (it might be a php
>> script returning GML
>>    for example)
>
> I'm pretty sure I follow this, but if an example lived somewhere it would be 
> great to see it.

Don't have stuff handy now (I'm stuck in bed with fever and the
notebook does not
have everything I need in working order) I'll try to look up more
examples when I get
back on my feet

Cheers
Andrea


-- 
Ing. Andrea Aime
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy

phone: +39 0584962313
fax:     +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-----------------------------------------------------

------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Reply via email to