On Fri, Nov 28, 2014 at 1:46 PM, Rahkonen Jukka (Tike) <
jukka.rahko...@mmmtike.fi> wrote:
> Thanks Andrea,
>
>
>
> for encouragement. I did not know that I can solve it but I learned to
> fiddle with the headers by using Firefox and Poster. The remote WMS server
> there simply does not like Java
GetCapabilities
User-Agent: foo
-Jukka-
Lähettäjä: andrea.a...@gmail.com [mailto:andrea.a...@gmail.com] Puolesta Andrea
Aime
Lähetetty: 28. marraskuuta 2014 14:32
Vastaanottaja: Rahkonen Jukka (Tike)
Kopio: geoserver-devel@lists.sourceforge.net
Aihe: Re: [Geoserver-devel] WMS cascading fails
On Fri, Nov 28, 2014 at 12:53 PM, Rahkonen Jukka (Tike) <
jukka.rahko...@mmmtike.fi> wrote:
> Hi,
>
> Captured from a gis.stackexchange question
> http://gis.stackexchange.com/questions/123754/problem-with-connecting-remote-wms-connection-to-geoserver,
> this WMS server can't be cascaded with Geos
Hi,
Captured from a gis.stackexchange question
http://gis.stackexchange.com/questions/123754/problem-with-connecting-remote-wms-connection-to-geoserver,
this WMS server can't be cascaded with Geoserver.:
http://mapy.geoportal.gov.pl/wss/service/pub/guest/kompozycjaG2_TBD_WMS/MapServer/WMSServer?
Hi List,
Is there a possibility to configure an other GFI Format for cascading WMS
Layers?
I found this in the documentation.
“GetFeatureInfo. WMS GetFeatureInfo requests will be passed to the remote WMS.
If the remote WMS supports the application/vnd.ogc.gml format the request will
be success
Hi all,
the WMS cascading work has been committed to trunk and is
available for all developer to play with today, and should
be available for everybody else starting tomorrow, by using
a trunk nightly build:
http://gridlock.openplans.org/geoserver/trunk/
The only bit missing is documentation, but
Justin Deoliveira ha scritto:
> On 5/5/10 12:27 AM, Andrea Aime wrote:
>> Ben Caradoc-Davies ha scritto:
>>> On 30/04/10 00:41, Justin Deoliveira wrote:
I have become quite a proponent of git these days, i use it for all
local development and for branch development nothing beats it.
>>>
>
+1
Wow, that is pretty cool. It would make writing clients a lot easier,
and shift some compositing load to the middleware. Great idea.
Kind regards,
Ben.
On 05/05/10 23:29, Andrea Aime wrote:
> Hi,
> the WMS cascading proposal is ready for your commenting/voting pleasure:
>
> http://geoserver
On 5/5/10 12:27 AM, Andrea Aime wrote:
> Ben Caradoc-Davies ha scritto:
>> On 30/04/10 00:41, Justin Deoliveira wrote:
>>> I have become quite a proponent of git these days, i use it for all
>>> local development and for branch development nothing beats it.
>>
>> I have seen the git header in your
Hi,
the WMS cascading proposal is ready for your commenting/voting pleasure:
http://geoserver.org/display/GEOS/GSIP+47+-+WMS+cascading
This afternoon I'll try to work out the lack of RESTConfig support,
seems the most important limitation to me atm
Cheers
Andrea
--
Andrea Aime
OpenGeo - http:
Ben Caradoc-Davies ha scritto:
> On 30/04/10 00:41, Justin Deoliveira wrote:
>> I have become quite a proponent of git these days, i use it for all
>> local development and for branch development nothing beats it.
>
> I have seen the git header in your patches. :-)
I have to second Justin's opin
On 30/04/10 00:41, Justin Deoliveira wrote:
> I have become quite a proponent of git these days, i use it for all
> local development and for branch development nothing beats it.
I have seen the git header in your patches. :-)
--
Ben Caradoc-Davies
Software Engineering Team Leader
CSIRO Earth
David Winslow ha scritto:
> Something to keep in mind is that git's svn integration can't push
> "merge commits" (ie, where two git branches join back together,
> something that should come up a lot in collaborative situation) from git
> to SVN. You *can* have as many branches off of a SVN sour
Something to keep in mind is that git's svn integration can't push
"merge commits" (ie, where two git branches join back together,
something that should come up a lot in collaborative situation) from git
to SVN. You *can* have as many branches off of a SVN source tree as you
want, but you will
I have become quite a proponent of git these days, i use it for all
local development and for branch development nothing beats it. The
reason being the rebasing. A few more comments inline.
On 4/28/10 8:49 AM, Jody Garnett wrote:
> Trunk is open for new development; any idea on the time frame fo
Trunk is open for new development; any idea on the time frame for WMS cascade
work? Do we have any need to release from trunk prior to FOSS4G (ie early July
deadline).
I do like the idea of trying out GIT on a "shared branch" like this. It would
give us a chance to learn.
Aside: Jesse took a
Hi,
the WMS cascading work is about to start, we'll need a place
where multiple people can share their work.
Options:
- work directly on trunk.
Upsides: it's easy, requires no extra setup/software
Downsides: it might result in breakages of trunk
- create a branch
Upsides: requires no extr
On 4/19/10 10:15 AM, Andrea Aime wrote:
> Justin Deoliveira ha scritto:
>> On 4/19/10 9:15 AM, Andrea Aime wrote:
>>> Justin Deoliveira ha scritto:
> A "native implementation" would require creating new
> configuration objects, WMSStoreInfo, WMSLayerResource,
> and possibly a WMSLayerIn
Justin Deoliveira ha scritto:
> On 4/19/10 9:15 AM, Andrea Aime wrote:
>> Justin Deoliveira ha scritto:
A "native implementation" would require creating new
configuration objects, WMSStoreInfo, WMSLayerResource,
and possibly a WMSLayerInfo.
WMSStoreInfo would hold a reference to
On 4/19/10 9:15 AM, Andrea Aime wrote:
> Justin Deoliveira ha scritto:
>>> A "native implementation" would require creating new
>>> configuration objects, WMSStoreInfo, WMSLayerResource,
>>> and possibly a WMSLayerInfo.
>>> WMSStoreInfo would hold a reference to the remote store
>>> and provide a l
Justin Deoliveira ha scritto:
>> A "native implementation" would require creating new
>> configuration objects, WMSStoreInfo, WMSLayerResource,
>> and possibly a WMSLayerInfo.
>> WMSStoreInfo would hold a reference to the remote store
>> and provide a list of available layers, WMSLayerResource
>> w
I think I agree with Jesse while the hack is tempting it seems doing it
the "right way" will provide much more flexibility in the end.
This will be a really great feature that I am sure users will go crazy
for. A few comments/questions inline.
On 4/16/10 10:08 AM, Andrea Aime wrote:
> Hi all,
>
As appealing as it is to quickly hack together WMS cascading through WCS I
think we need the native support. If we went the WCS route we would get
lots of bug reports around GetFeatureInfo, etc... Also the layers would show
up as a Coverage in WCS requests which is misleading.
Also +1 to getting
Hi all,
I'm writing this mail to start some discussion and gather
some feebdack on a feature that we are going to implement
sometimes soon: WMS cascading (warning, long mail).
It is something that deserves its own GSIP of course, with
this mail I'm just trying to introduce the topic and consider
a
24 matches
Mail list logo
