Hi Andrea,
Thanks for the awesome support you guys are giving here.
My personal experience in this list began with an unanswered message,
then I poked everybody a little bit and got answered really fast, so I
appreciate your e-mail.
I do my best to be helpful, and most of my e-mail exchanges
Hello James,
You have to build the sources using maven and then copy the generated
war to your tomcat folder. As you have seen, it does not work if you
just copy everything to the tomcat folder before running "mvn clean
install".
See
Andrea beat me to the answer...
Is it possible to set transparency "style - wide" instead of
individually for symbolizers? I was trying to find a way to make
transparency work for that case.
I suppose one could implement the transparency when rendering at the
client, but it would be best if
essage --
> From: *Thomas* <skullg...@gmail.com <mailto:skullg...@gmail.com>>
> Date: 2017-03-23 15:21 GMT+01:00
> Subject: Re: [Geoserver-users] Geoserver reload issue
> To: Daniel Araujo Miranda <miranda@dpf.gov.br
> <mailto:miranda@dpf.gov.br>>
Hello jtour,
I will make a random sugestion (pun intended):
Try installing haveged to see if it has any effect on your layer
creation times.
In my case, the entropy pool (the O.S. randomness source) was low,
which means GeoServer took a long time to start because of some Tomcat
Hi everyone!
I have been stuck with this for the better part of a day already. I
am trying to use geofence with a nightly 10.x geoserver with JDBCConfig
and JDBCStore. Everything went fine until I unzipped the geofence war to
the webapps folder and restarted tomcat.
I get a
Here is what I can think of:
You can set individual permissions per each workspace/layer combination,
including the wildcard "*" for every layer on a specific workspace or
"*.*" for every layer in every workspace.
For example:
role "Editor" has edit access to "Area1".* (all layers of
rry, I'm an old fashion guy from ZX Spectrum generation, used to
> count bits, and Z80 timestates... ;-)
>
>
> 2017-01-31 12:22 GMT+00:00 Daniel Araujo Miranda
> <miranda@dpf.gov.br <mailto:miranda@dpf.gov.br>>:
>
> Hi, Ricardo,
>
> Yo
Hi, Ricardo,
Your geoserver already starts in a reasonable time. I was unsettled
with my installation because it took six minutes. Since haveged did not
change the time needed to run your test, it seems geoserver (actually
tomcat8) is not limited by entropy on startup.
To make sure
>
> Chris Snider
> Senior Software Engineer
> Intelligent Software Solutions, Inc.
>
>
>
> -----Original Message-
> From: Daniel Araujo Miranda [mailto:miranda@dpf.gov.br]
> Sent: Friday, January 27, 2017 12:26 PM
> To: Chris Snider <chris.sni...@is
how-to-setup-additional-entropy-for-cloud-servers-using-haveged
>
> I was able to keep our securerandom.source on /dev/random.
>
> Chris Snider
> Senior Software Engineer
> Intelligent Software Solutions, Inc.
>
>
> -Original Message-
> From: Daniel Araujo Miran
Hello everyone,
TLDR: Change the line "securerandom.source=file:/dev/random" in
"/etc/java-8-openjdk/security/java.security" to point to /dev/urandom
instead to start a clean geoserver install in 13 seconds instead of 6
minutes. Be mindful of security implications.
I have been
Hello Beatrice,
The quick suggestion is:
Try to learn a little bit about QGis separately (just search the
web for 'qgis tutorial') before trying to use QGis and Geoserver together.
The long answer is:
I don't know exactly what you mean with "don't have experience in
this field", so
Hi Volkan, please take a look at these issues:
https://osgeo-org.atlassian.net/browse/GEOS-7653
https://osgeo-org.atlassian.net/browse/GEOS-6818
The first one was submitted by me, it may just be that your problem is
related to that. If so, please chime in and generate some activity for
the
I lookup as well; it
> depends on your servlet container how dynamic ths actually is; it may
> need to be restarted as well.
>
>
>> On Fri, Aug 19, 2016 at 8:13 AM, Daniel Araujo Miranda
>> <miranda@dpf.gov.br <mailto:miranda@dpf.gov.br>> wrote:
>&g
Hi David,
I am not sure I quite understood your use case, but here's an idea:
You may point you datasources to a local host address defined in
/etc/hosts (for example: "geoserverdatabase"), preferably one that is
not resolvable by your internal dns.
To change between
Chris and Ian,
Pelase note that the geowebcache url in the geoserver user interface is
bugged and still points to '127.0.0.1:8080' (localhost) even if you set
proxy base url correctly. The service works fine, but the page links to
the wrong address.
See
g, 2.6.5 and 2.8.4; and interestingly it seems to be working
> on 2.8.4.
>
> I wonder if it was a bug which has since been fixed?
>
> Thanks,
> Paul
>
> -Original Message-
> From: Daniel Araujo Miranda [mailto:miranda@dpf.gov.br]
> Sent: 11 August 2016 14:42
&g
I also have the same issue.
I may have found the problem in the code and I am itching to submit a
patch, but I have not touched Java in more than 10 years and I am not
familiar with this codebase. I reported the issue instead:
https://osgeo-org.atlassian.net/browse/GEOS-7653
Problem
Hi Simon,
I have no experience with rendering transformations, but I would
suggest you first check the basics again (configuration was ported
correctly, test conditions for your two examples are the same).
Then maybe try finding the change in the WPS module from 2.2.5 to
your current
Hi Srikanth, please clarify.
Did you click on "Layer Preview" and then on "OpenLayers" and you got
that XML error on the browser window?
Please provide the actual url used. For example, in my case an
OpenLayers preview works fine and leads me to:
nality, or indirectly by using the work as an
> example/inspiration).
>
>
> --
> Jody Garnett
>
> On 8 July 2016 at 04:54, Daniel Araujo Miranda <miranda@dpf.gov.br
> <mailto:miranda@dpf.gov.br>> wrote:
>
> Hi everyone!
> In
Thank you Brad! I found the downloadable module at the place you indicated.
The support absence is perfectly ok. I am going for it because the
functionality is absolutely awsome for my use case.
--Daniel
Em 09/07/2016 07:03, Brad Hards escreveu:
>>>I am trying to download the
the answer to mine or any other question,
please chime in.
Thanks to all, this is a great community around a great project.
--Daniel
Em 05/07/2016 13:08, Daniel Araujo Miranda escreveu:
> Hi, everyone.
> I am trying to download the JDBCConfig module for installation in
> my new geos
Hi Cosme,
How did you check out the geometries were ok? Did you run an actual
validity check like ST_IsValid or did you inspect them visually? It
might be that the "interiorPoint" algorithm uncovered something odd that
is not evident to the eye.
From what you have written, the problem is
I get that when I try to zoom out (not in) on a really crowded layer,
but it has nothing to do with geoserver versions.
May I suggest you try a vanilla style on your layer and see if the issue
continues?
It might be that something in the SLD is handled differently on your new
geoserver
Hi Milton,
That kind of url returns a perfectly valid kml for me that opens in
Google Earth.
A wrong setting in the "Proxy Base URL" field will show as an invalid
address in the ... field inside your kml. Check
if that WMS address inside the KML is valid.
If it is not, fix
Hi, everyone.
I am trying to download the JDBCConfig module for installation in
my new geoserver 2.9 server, and I cannot find the file for download.
Here is what I tried:
-Read the docs at
http://docs.geoserver.org/stable/en/user/community/jdbcconfig/installing.html
-Went to
28 matches
Mail list logo
