> WMS and GetMapRequest: The STYLE_URL, STYLE_BODY, STYLE_FORMAT are all
>> clear ... do you need a STYLE_VERSION as par of this?
>>
>> SLD_VERSION is part of the WMS 1.3 spec, so it's needed afaik, and
> because of that STYLE_VERSION made sense given we are giving the rest of
> the parameters gene
On Mon, Jul 14, 2014 at 5:45 PM, Jody Garnett
wrote:
> Quick feedback:
>
> WMS and GetMapRequest: The STYLE_URL, STYLE_BODY, STYLE_FORMAT are all
> clear ... do you need a STYLE_VERSION as par of this?
>
> SLD_VERSION is part of the WMS 1.3 spec, so it's needed afaik, and because
of that STYLE_VE
> Phil perhaps it was not obvious, but this extension generates a normal
> GeoTools Style object (i.e. the same object we parse out of an SLD
> file). Thus there is no change needed to the GeoTools rendering code.
Okay then. This was the abstraction I was looking for.
Notice: This email and an
Phil perhaps it was not obvious, but this extension generates a normal
GeoTools Style object (i.e. the same object we parse out of an SLD file).
Thus there is no change needed to the GeoTools rendering code.
That said if you *want* to splice it a bit of custom rendering the GeoTools
API provides a
One of the pull requests that has been discussed is
https://github.com/geoserver/geoserver/pull/638 Swapping out wfs for wfs-ng
What was the verdict coming out of testing? The pull request itself is
straightforward, but I would like to see wfs-ng go supported on
geotools-devel first.
--
Jody Garne
interesting. I like the idea of possible alternatives to SLD (preferably
something a lot less verbose - you can allow users to some interesting
map analysis which translates down into sending a different SLD.)
However, surely the reality is going to be a lot duplication on the
renderer code req
Quick feedback:
WMS and GetMapRequest: The STYLE_URL, STYLE_BODY, STYLE_FORMAT are all
clear ... do you need a STYLE_VERSION as par of this?
Feedback / Questions on implementation:
- Would it be more clear to have SLD 1.0 and SE 1.1 each with their
own StyleHandler?
- Recommend chaining:
void e
Hi all,
I updated the code based on feedback from last week and wrote up the
proposal.
https://github.com/geoserver/geoserver/wiki/GSIP-117-Pluggable-Styles
It would be great to get this in by feature freeze but I realize I am not
leaving all that much time for folks to review.
-Justin
--
J
Hi Jerome:
I have been looking into a similar dependency audit for GeoTools for the
Eclipse Foundation as part of the LocationTech working group. My effort is
only going as far as rounding up all the jars needed for the uDig project,
but the process is similar.
You will find that the maven pom.xm
Hello,
My name is Jérôme and I'm currently working on a GSoC project to package
differents GIS Softwares and one of goals this summer is working on
packaging Java softwares like GeoServer and GeoTools.
I know there is already a GeoServer package, but it's not built in a way
that would be accep
Looks good Mauro, will merge (with a few minor javadoc fixes).
--
Jody
Jody Garnett
On Mon, Jul 14, 2014 at 6:33 AM, Mauro Bartolomeoli <
mauro.bartolome...@geo-solutions.it> wrote:
> Hi Jody,
>
>
> 2014-07-11 19:24 GMT+02:00 Jody Garnett :
>
> To answer your question there is no standard way f
Sadly I did not, got stuck reviewing the geometry work. I will look at it
first thing this morning.
Jody Garnett
On Mon, Jul 14, 2014 at 6:33 AM, Mauro Bartolomeoli <
mauro.bartolome...@geo-solutions.it> wrote:
> Hi Jody,
>
>
> 2014-07-11 19:24 GMT+02:00 Jody Garnett :
>
> To answer your questi
Hi Jody,
2014-07-11 19:24 GMT+02:00 Jody Garnett :
> To answer your question there is no standard way for "cache files" rather
> than "configuration files". Until we had a few more examples (other than
> geowebcache) it was not worth introducing an API. I don't see any issuing
> getting this mer
13 matches
Mail list logo
