Re: [Geoserver-devel] reminder - release-candidate next week

[Jim Hughes]

Hi Jody,

I had chatted with Martin about a JTS bug fix.  Evidently he has found 
something small in the OverlayNG code which is available for users to 
try out optionally.


Is upgrading to a JTS bug fix for the RC sensible?

Cheers,

Jim

On 2/22/21 10:33 PM, Jody Garnett wrote:
Reminder, the release candidate is scheduled for next week - please 
take a look for any outstanding pull requests and pitch in if you can. 
If you have any work in progress that was waiting for review or 
feedback please speak up also.

--
Jody Garnett


___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel



___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] New Vector to vector GroupingRenderingTransformation

[Jim Hughes]

Hi Marco,

It seems like such a rendering transformation would be very handy.

One question that I'd have is if there's an obvious way to let 
DataStores push down the aggregations to the underlying databases?  
Maybe there could be a GroupingVisitor that could carry out the 
computation or represent the work that the DataStore would have to do 
for the FeatureCollection?


I suppose I'm thinking about something like the MinVisitor: 
https://github.com/geotools/geotools/blob/master/modules/library/main/src/main/java/org/geotools/feature/visitor/MinVisitor.java 
which implementations can optimize for: 
https://github.com/geotools/geotools/blob/master/modules/unsupported/solr/src/main/java/org/geotools/data/solr/SolrFeatureSource.java#L440-L449.


As a second thought/question, could aggregationAttribute be an 
expression or would it need to be an attribute in the SimpleFeatureType?


In GeoMesa, we added a WPS process to compute statistics.  This is 
making me think of that process a little bit and some of the 
optimizations which can be applied.  So yeah, big plus one to this idea; 
having this as rendering transformation should open up some interesting 
styling options!


Cheers,

Jim

On 9/29/20 5:19 AM, Marco Volpini wrote:

Dear all,
I'm writing to propose the creation of a new vector rendering 
transformation and have your feedback about it. The following listing 
shows how it would appear:


| name="vec:GroupingRenderingTransformation"> name="parameter"> data  
 
groupByAttributes 
attribute1 
attribute2  
attributeN name="parameter">  
aggregator min 
  
aggregationAttribute 
attributeName  
 |


  * the groupByAttributes parameter allows to define the feature's
attributes to produce the groups on which do aggregation;
  * the aggregator parameter specifies the aggregation to perform (eg.
min/max);
  * the aggregationAttribute provides the feature attribute used for
the aggregation.

For instance, in case of a min aggregation, the rendering 
transformation will allow to return only the feature, for each group, 
having the minimum value for the aggregationAttribute.


Moreover, in order to give a consistent result, the rendering 
transformation will need to be fed with sorted features.
This would allow to overcome issues that would arise if sorting is 
handled inside the RT:


  * FeatureCollection sort method accepts only one SortBy object,
while the RT would allow to define more grouping attributes.
  * The FeatureCollection sort method doesn't support ComplexFeatures.

In case the RT is issued through a sld, the sortBy attributes can be 
defined through the vendorOption, while in case of a WPS process, they 
can be provided through the Query object.


The output of the rendering transformation will be a FeatureCollection 
wrapper, and the necessary computation will be performed in the 
hasNext method of the corresponding FeatureIterator.


Best regards,

Marco Volpini




___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel



___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] Monitor extension questions

[Jim Hughes]

Hi all,

First, the monitor extension is awesome!  If you are unfamiliar with it, 
I recommend giving it a look.


Second, I want to acknowledge that my questions (potential changes) may 
be pointing to things which would negatively impact existing 
implementations.  As such, I'm fine with a blanket "No, we really 
shouldn't do that..." as a response.


That said, I've opened PR here: 
https://github.com/geoserver/geoserver/pull/4503 to show the 
questions/changes I'm curious about.


As I implemented a quick implementation of RequestDataListener, I 
noticed that successful OWS requests fired 4 messages through (failures 
sent 5).  Of those messages, I think only two of them are useful and my 
changes would remove some of the (potentially) redundant calls.


Thanks in advance for any feedback,

Jim



___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] Eclipse EMF dependencies in GeoTools and GeoServer

[Jim Hughes]

Hi all,

A colleague noticed that GeoTools is pointing at one version of Eclipse 
EMF jars[1] and GeoServer is pointing at another[2].


Anyhow, it appears that version 2.15.0 is available for all the 
dependencies GeoTools/GeoServer uses, so I've tossed up PRs to update to 
Eclipse EMF versions 2.15.0:


https://github.com/geotools/geotools/pull/3072
https://github.com/geoserver/geoserver/pull/4419

I imagine if CI/CD builds, then we should be 'good to go'. Admittedly, I 
just tossed this together quickly, and I'm not an EMF expert.  My goal 
is to help keep dependencies lined up:).


Let me know if I can help with this one any more.

Cheers,

Jim

1. https://github.com/geotools/geotools/blob/master/pom.xml#L1291-L1310
2. 
https://github.com/geoserver/geoserver/blob/master/src/pom.xml#L1062-L1081




___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] All committer please notice: cleanup in progress, please follow up with this mail ASAP (GSIP-180)

[Jim Hughes]

Hi Andrea,

I've subscribed to all three email lists!  (Wasn't subscribed to the 
builds list before.)


Cheers,

Jim

On 10/26/19 5:47 AM, Andrea Aime wrote:

Hi,
as per GSIP-180 I'm cleaning up the list of GeoServer committers. 
Phase one, removing the developers

that have not been active in the last year, has been done.

Now it's time to proceed to phase two, check that all remaining 
committers are participating to the

community, and are subscribed to the devel, build and user lists.
I have prepared a spreadsheet with the current list of committers and 
their list status here (accessible read only):

https://docs.google.com/spreadsheets/d/18wWH9pTcKDdZaVOK3N8W4po01VprO3e9n08ihEELdIs/edit#gid=0

I cannot access the list rosters anymore (GPDR I presume) so please 
reply to this thread confirming your mail list

subscription status.
I'll wait two weeks, and then remove commit access from anyone that 
did not respond to this mail, or those

that answered but are unwilling to take part on the lists.

If anyone failed to see the message due to a vacation, work trip, and 
whatever other reason,
and got removed, no worries, we will happily reinstate access once you 
comply with the community participation :-D


I remind you that being committer is not a requirement for general 
community participation, it just allows

direct commit, PR merge rights, wiki editing (including GSIP writing)
and allows for release management. Other activities like PSC 
participation are still possible, and code contributions

are still possible via pull requests.

If you read this mail and don't see your name in the list above, but 
need commit rights to maintain a community

module or similar activities, also please let us know.

Cheers
Andrea

== GeoServer Professional Services from the experts! Visit 
http://goo.gl/it488V for more information. == Ing. Andrea Aime 
@geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 
55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: 
+39 339 8844549 http://www.geo-solutions.it 
http://twitter.com/geosolutions_it 
--- /Con 
riferimento alla normativa sul trattamento dei dati personali (Reg. UE 
2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si 
precisa che ogni circostanza inerente alla presente email (il suo 
contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è 
riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il 
messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra 
operazione è illecita. Le sarei comunque grato se potesse darmene 
notizia. This email is intended only for the person or entity to which 
it is addressed and may contain information that is privileged, 
confidential or otherwise protected from disclosure. We remind that - 
as provided by European Regulation 2016/679 “GDPR” - copying, 
dissemination or use of this e-mail or the information herein by 
anyone other than the intended recipient is prohibited. If you have 
received this email by mistake, please notify us immediately by 
telephone or e-mail./




___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel



___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] circle-ci cross project integration tests

[Jim Hughes]

Hi Andrea,

Congrats, this is awesome!  I'm glad you were able to clean up what I 
started at the OSGeo code sprint!


Cheers,

Jim

On 5/19/2019 5:18 PM, Andrea Aime wrote:

Hi,
following on Jim's work I've prepared a build that seems to be doing 
the trick, and building

in sequence:

  * GeoTools (without tests, other builds cover that)
  * GeoWebCache (with tests)
  * GeoServer (with tests and community modules compile only)

All build in sequence in the same container, thus using the same 
repository and, what's important,

the same snapshots produced by the GeoTools build.

Jim was right, making the silly thing build without breaking on build 
limits has been the challenging
point, took a number of experiments to find the right way to pass the 
JVM params and set them

to a working condition.
Build times are surprisingly not bad, around 20 minutes total, which 
is compatible with the other

Travis builds the PRs are triggering.

Here is the build file:
https://github.com/aaime/geotools/blob/circle/.circleci/config.yml

and branch:
https://github.com/aaime/geotools/tree/circle

A successful build looks as follows:

image.png

I'm sure some adjustments are going to be needed, and we won't be able 
to trust these builds always
(like if a PR is meant to introduce a breaking change, well, it will 
break this build for sure).
I can imagine maybe some conventions in the commit message referring 
to the repos
and branches for the corresponding gwc and gs to use but... I'll leave 
that as an exercise for those

interested :-p

If there are no objections I can make a PR to introduce this in 
GeoTools in the next few days.


Cheers
Andrea

PS: and yes, we'll need to setup a similar build for GeoWebCache too, 
to check eventual downstream

breakage in GeoServer.

== GeoServer Professional Services from the experts! Visit 
http://goo.gl/it488V for more information. == Ing. Andrea Aime 
@geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 
55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: 
+39 339 8844549 http://www.geo-solutions.it 
http://twitter.com/geosolutions_it 
--- /Con 
riferimento alla normativa sul trattamento dei dati personali (Reg. UE 
2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si 
precisa che ogni circostanza inerente alla presente email (il suo 
contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è 
riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il 
messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra 
operazione è illecita. Le sarei comunque grato se potesse darmene 
notizia. This email is intended only for the person or entity to which 
it is addressed and may contain information that is privileged, 
confidential or otherwise protected from disclosure. We remind that - 
as provided by European Regulation 2016/679 “GDPR” - copying, 
dissemination or use of this e-mail or the information herein by 
anyone other than the intended recipient is prohibited. If you have 
received this email by mistake, please notify us immediately by 
telephone or e-mail./




___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] [Geotools-devel] GeoTools PR reviews and downstream builds

[Jim Hughes]

Hi all,

While at the OSGeo code sprint, I spent some time working with 
CircleCI.  The goal was to see if one build could chain multiple repos 
together.  That is, could a CircleCI job build GeoTools, GeoWebCache, 
and GeoServer?


The good news is that CircleCI is flexible enough to chain builds.  I 
put together a dummy example of that with JTS and Hatbox[1].  I was able 
to see a failure on a branch of JTS where I changed the name of class 
that Hatbox uses.


When I tried to setup a GeoTools build[2], I ran into problems where I 
was unable to get the project to build.  I may have screwed up something 
with the job config or we need a bigger box from CircleCI (which would 
cost money).


Since I wasn't finding good examples and was generally having trouble, I 
moved on to working with Jody on ImageN.


Anyone who is interested is more than welcome to my branches. Also, I'm 
happy to answer any questions.  Wish I had better news...


Cheers,

Jim

1. https://github.com/jnh5y/jts/blob/circleci/.circleci/config.yml
2. https://github.com/jnh5y/geotools/blob/circleci/.circleci/config.yml

On 5/14/2019 2:49 AM, Andrea Aime wrote:

Hi Jody,
this worries me... the build server is showing long build queues with 
the current workload,

if we add more, we should also provision more build power imho?

Cheers
Andrea

On Mon, May 13, 2019 at 10:54 PM Jody Garnett > wrote:


When build.geoserver.org  is back we
should be able to configure it to check pull request branches and
do a long build chain as you describe Andrea.
--
Jody Garnett


On Mon, 13 May 2019 at 14:22, Chris Snider
mailto:chris.sni...@polarisalpha.com>> wrote:

Is any part of the build chain Jenkins?  I know Jenkins can
call a build script from another branch of the same
repository, but it may also work to call a build job from a
different repository.  I plan on investigating this process
for our in-house builds for a project I moved to. Might be
worth someone with access to the build servers to investigate
cross-repository builds?

Chris Snider

Senior Software Engineer

pa-logo-email

*From:* Andrea Aime mailto:andrea.a...@geo-solutions.it>>
*Sent:* Monday, May 13, 2019 10:37 AM
*To:* Geotools-Devel list
mailto:geotools-de...@lists.sourceforge.net>>;
Geoserver-devel mailto:geoserver-devel@lists.sourceforge.net>>
*Subject:* Re: [Geoserver-devel] GeoTools PR reviews and
downstream builds

On Mon, May 13, 2019 at 5:29 PM Andrea Aime
mailto:andrea.a...@geo-solutions.it>> wrote:

Was wondering if this could be delegated to the build
server, rough idea:

  * Add a entry in the build matrix that runs a custom
shell script
  * The script build geotools without tests (the other
builds cover that) in order to have fresh local GT
jars in the maven repository
  * The script then check out GeoServer sources, and
builds it with tests
  * Repeat the above steps for GWC as well

However, I have no idea if a build matrix entry is even
allowed to do the above.

Has anyone experiences trying to do anything similar

Another possibility would be to run the custom script on
another build platform. Has anyone experience for example with
circle-ci?

I see they provide 4 build containers to open source projects:

https://circleci.com/open-source/

Open to other free alternatives too, bring them in.

Cheers

Andrea

==

GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information. == Ing. Andrea Aime
@geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito
3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584
1660272 mob: +39 339 8844549 http://www.geo-solutions.it
http://twitter.com/geosolutions_it
--- /Con
riferimento alla normativa sul trattamento dei dati personali
(Reg. UE 2016/679 - Regolamento generale sulla protezione dei
dati “GDPR”), si precisa che ogni circostanza inerente alla
presente email (il suo contenuto, gli eventuali allegati,
etc.) è un dato la cui conoscenza è riservata al/i solo/i
destinatario/i indicati dallo scrivente. Se il messaggio Le è
giunto per errore, è tenuta/o a cancellarlo, ogni altra
operazione è illecita. Le sarei comunque grato se potesse
darmene notizia. This email is intended only for the person or
entity to which it is addressed and may contain information
that is privileged, confidential or otherwise protected from
  

Re: [Geoserver-devel] Geoserver and JMS clustering

[Jim Hughes]

Jody,

Is it worth looking into publishing GeoTools (and maybe GWC/GS) on Maven 
Central?


Cheers,

Jim

On 4/30/19 3:06 PM, Jody Garnett wrote:
Gabriel I was looking at setting up a Artifactory or Nexus for the 
geotools project.


If you want a community space to share docker containers I should 
choose Nexus (which has docker support out of the box).

--
Jody Garnett


On Mon, 29 Apr 2019 at 16:39, Gabriel Roldan > wrote:


Earlier this month I've gave a workshop on geoserver clustering
configuration.

Used the JMS cluster community module with a dedicated ActiveMQ
broker, which worked fantastically, great job there.

It loads balance with a dockercloud/haproxy docker container and
uses sticky sessions to access the web UI, so no need to have a
dedicated "master" with UI access. I know there are a thousand
topologies you can use, but this one seemed just so easy for an
introductory course and worked so well that I was impressed.

You can check this docker-compose config [1]

The only pitfall to get it running properly on docker was to
change the activemq server uri to use the 0.0.0.0 IP address,
you'll see in the Dockerfile[2]
"-Dactivemq.transportConnectors.server.uri=\"tcp://0.0.0.0:61666
" added to the CATALINA_OPTS env variable.
This is so the server listens on all interfaces and not just the
loopback one 127.0.0.1. It would be great if the default was
changed from 127.0.0.1 to 0.0.0.0

The other trick was to dynamically give each instance a unique id,
which is done in the geoserver instance config by overriding the
docker image's startup comment with "command: /bin/bash -c
"instanceName=$$(/bin/hostname) /usr/local/bin/start.sh"

All in all, I'm really enthusiastic about these community modules
and hope to contribute asap.

Finally, thanks a lot to GeoSolutions for letting me use their
documentation [3] to prepare the workshop's material.

[1]


[2]


[3] 
-- 
Gabriel Roldán

___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/geoserver-devel



___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel



___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Vector tiles pipeline: why simplifying before clipping?

[Jim Hughes]

As of JTS 1.16, there isn't a single makeValid call.:(

When I've heard it discussed, it sounds like makeValid functions are 
usually a bunch of tricks applied one after another to try and fix up a 
topology.


*shrugs*

Jim


On 11/13/18 9:31 AM, Andrea Aime wrote:
On Tue, Nov 13, 2018 at 3:08 PM Gabriel Roldan 
mailto:grol...@boundlessgeo.com>> wrote:


Hello,

I don't think there's any good reason for simplifying before
clipping. Maybe just not having tested or thought too much about
it. I do remember though that without topology preserving
simplification we ran into a number of issues with the resulting
tiles, to my deception, knowing it's so much slower than
Douglas Peuker.


Yes indeed, unfortunately the vector tiles spec wants valid polygons, 
so no "fast lane" for us.
Had a quick look at tippecanoe's code, seems to be using a normal DP, 
believe they are then calling
this library to clean it up in post-processing: 
https://github.com/mapbox/wagyu
I guess it could be faster than JTS topological preserving DP, the 
spec does not say specifically about topologically valid geoms, but it 
states "Polygon geometries MUST NOT have any interior rings that 
intersect and interior rings MUST be enclosed by the exterior ring."
Maybe doing DP and then fixing the output would be faster, but I'm not 
sure JTS has a "make valid" operator (it did not, but who knows now)
cannot see one, but found this: 
https://locationtech.github.io/jts/javadoc/org/locationtech/jts/simplify/VWSimplifier.html


I'll prepare a pull request to switch the two ops in the meantime.

Cheers
Andrea
==

GeoServer Professional Services from the experts! Visit 
http://goo.gl/it488V for more information. == Ing. Andrea Aime 
@geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 
55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: 
+39 339 8844549 http://www.geo-solutions.it 
http://twitter.com/geosolutions_it 
--- /Con 
riferimento alla normativa sul trattamento dei dati personali (Reg. UE 
2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si 
precisa che ogni circostanza inerente alla presente email (il suo 
contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è 
riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il 
messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra 
operazione è illecita. Le sarei comunque grato se potesse darmene 
notizia. This email is intended only for the person or entity to which 
it is addressed and may contain information that is privileged, 
confidential or otherwise protected from disclosure. We remind that - 
as provided by European Regulation 2016/679 “GDPR” - copying, 
dissemination or use of this e-mail or the information herein by 
anyone other than the intended recipient is prohibited. If you have 
received this email by mistake, please notify us immediately by 
telephone or e-mail./




___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel



___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Vector tiles pipeline: why simplifying before clipping?

[Jim Hughes]

Hi Andrea,

Generally, this seems like the much safer approach.  I could imagine 
lines moving a little bit if you do things in the other order.


That said, is there any room to leverage the pre-generalized DataStore 
tricks along the way here?  It seems like that's a nice technique to 
dealing with situations where there are millions of vertices.


Cheers,

Jim

On 11/11/18 5:05 AM, Andrea Aime wrote:

Hi,
following a report of slow vector tiles generation on the list I'm 
looking at the vector tiles pipeline builder
and found that topology preserving simplification is done before doing 
the clipping.
The use case reported by the user has a single large polygon detailing 
the shape of australia, islands included,

that contains 1.5 million vertices.

I've tried to switch simplification and clipping, doing clipping 
before, and the result seems to be much faster,

to the tune of 10 times on an simple "apachebench" benchmark.

Is there any correctness reason as to why simplification is done 
before clipping?
I've tried to dump the same vector tiles twice, with the two operation 
flipped, the geometries look pretty
much the same, only in one geometry I get the last point repeated 
twice at the end of the ordinate list (comes

out of the current code).

Cheers
Andrea

== GeoServer Professional Services from the experts! Visit 
http://goo.gl/it488V for more information. == Ing. Andrea Aime 
@geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 
55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: 
+39 339 8844549 http://www.geo-solutions.it 
http://twitter.com/geosolutions_it 
--- /Con 
riferimento alla normativa sul trattamento dei dati personali (Reg. UE 
2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si 
precisa che ogni circostanza inerente alla presente email (il suo 
contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è 
riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il 
messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra 
operazione è illecita. Le sarei comunque grato se potesse darmene 
notizia. This email is intended only for the person or entity to which 
it is addressed and may contain information that is privileged, 
confidential or otherwise protected from disclosure. We remind that - 
as provided by European Regulation 2016/679 “GDPR” - copying, 
dissemination or use of this e-mail or the information herein by 
anyone other than the intended recipient is prohibited. If you have 
received this email by mistake, please notify us immediately by 
telephone or e-mail./




___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel



___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] OSGeo Java Code Sprint 2018 (Stage 3)

[Jim Hughes]

Hi all,

As part of the GeoTools/GeoWebCache/GeoServer code sprint, we addressed 
a number of concerns.  The immediate goal was to do enough so that users 
could run GeoServer on Java 9/10/11.  Jody Garnett has an email thread 
describing the work that the sprint team completed this week to achieve 
that goal.


JDK 11's module path insists that packages come from only one jar.  Lots 
of GeoTools jars contribute to many of the same packages.  Reducing and 
eliminating these overlaps is one of our major goals for this week.  The 
refactoring was done in manner so that downstream changes in GeoServer 
were made at the same time.


At the end of sprint, we worked late to finish the last of the planned 
refactoring and merge out work.  There is some outstanding work to be done.


Outstanding TODOs:
* Any remaining split packages need to be identified.  (This tool[2] 
could be run against GT and GWC jars.)
* The changes in the spreadsheet[1] should be documented (and ideally 
set up as a nice sed script!).

* More testing for extensions and community modules would be great.

It's been a great week!  From our spreadsheet[1], we planned and 
documented migrating classes to different package names, and in some 
cases, moving packages between modules/jars to achieve this goal.  It is 
our expectation that we'll need to resolve this 'split package' problem 
for GeoTools first.  We do not expect to see J2EE web servers which will 
put software on the module path for a little while...  Given that, we 
expect the first use of the module path to be with the GeoTools library.


A big thanks goes to Jody!  Not only for organizing the week and hosting 
developers in Victoria, but also for planning the new package 
architecture.  Jody performed some of the initial repackaging in the 
core library.  Towards the end of the week, Andrea Aime joined us to do 
some of the refactoring as well. David Vick, Devon Tucker, Torben 
Barsballe and I pitched in to carry about the rest of the refactoring.  
Kevin Smith handled the repackaging for GeoWebCache.


I'm proud to be a member of this community and events like this are 
possible due to sponsorship and participation around the world.  Gaia3D, 
Astun Technology, OS Geo UK, and Atol all contributed to the financial 
needs of the event.  Astun, Boundless, CCRi, GeoCat, and GeoSolutions 
all provided staff to do the work.  David Vick wrote up some more 
details about the sprint here[3].


Cheers,

Jim

1. 
https://docs.google.com/spreadsheets/d/1oE6mU4jp-ZL5PebgXf-fuhtf7MY5dzSwPqpMtrzdZ94/ 


2. https://github.com/AdoptOpenJDK/jsplitpkgscan
3. https://www.linkedin.com/pulse/java-2018-code-sprint-david-vick/



___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] JDK 11: GeoTools restructure to address split-package restriction

[Jim Hughes]

Hi Jody,

I computed a quick list of package names outside of the 'library' that 
need to be moved to avoid the split module issues.  The attached files 
have that output.


This won't necessarily sort all the split modules, but it'd be a handy 
next step.


Cheers,

Jim

On 10/25/2018 2:49 AM, Jody Garnett wrote:
Updated spreadsheet plan, reviewed with team, and sent the updated 
proposal 
 to 
geotools-devel

- repackage plan is nice and solid
- splitting up gt-main is technically feasible - asking geotools-devel 
if we should do so


Initial pull request is here: 
https://github.com/geotools/geotools/pull/2142


1) redistribute gt-api classes to gt-metadata and gt-main
- Initial classes moved to gt-metadata successfully
- api change: org.geotools.decorate --> org.geotools.util.decorate
- note: DirectPosition3D had to move to gt-referencing (to preserve a 
package visibility "friend" relationship

- everything else moved to gt-main as planned
- gt-api successfully removed, and gt-main pom.xml description updated
- recording refactoring script and placed into user guide for later

Tomorrow: Continuing on with the core library tomorrow morning, moving 
on to plugins and extensions tomorrow afternoon. Goal is to finish up 
on Thursday, and apply these changes to geowebcache and geoserver 
projects Friday morning.


How to help?
- Love to hear how EMF upgrade is going (to see if our models can 
track api change)
- Need a sample application ready to test using geotools on the module 
path




--
Jody Garnett




___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


app-schema/app-schema/src/main/java/org/geotools/feature/AppSchemaAttributeBuilder.java
app-schema/app-schema/src/main/java/org/geotools/feature/AppSchemaFeatureFactoryImpl.java
app-schema/app-schema/src/main/java/org/geotools/filter/AsMultiGeometryFunctionExpression.java
app-schema/app-schema/src/main/java/org/geotools/filter/expression/FormatDateTimezoneFunction.java
app-schema/app-schema/src/main/java/org/geotools/filter/expression/ToDirectPositionFunction.java
app-schema/app-schema/src/main/java/org/geotools/filter/expression/ToEnvelopeFunction.java
app-schema/app-schema/src/main/java/org/geotools/filter/expression/ToLineStringFunction.java
app-schema/app-schema/src/main/java/org/geotools/filter/expression/ToPointFunction.java
app-schema/app-schema/src/main/java/org/geotools/filter/expression/ToXlinkHrefFunction.java
app-schema/app-schema/src/main/java/org/geotools/filter/expression/VocabFunction.java
app-schema/app-schema/src/main/java/org/geotools/filter/expression/XmlXPathPropertyAccessorFactory.java
app-schema/app-schema/src/main/java/org/geotools/filter/FilterFactoryImplNamespaceAware.java
app-schema/app-schema/src/main/java/org/geotools/filter/FilterFactoryImplReportInvalidProperty.java
app-schema/app-schema/src/main/java/org/geotools/filter/IDFunctionExpression.java
app-schema/app-schema/src/main/java/org/geotools/filter/NestedAttributeExpression.java
app-schema/app-schema/src/main/java/org/geotools/jdbc/JdbcMultipleValueEncoder.java
app-schema/app-schema/src/main/java/org/geotools/jdbc/JoiningJDBCFeatureSource.java
app-schema/app-schema/src/main/java/org/geotools/jdbc/NamespaceAwareAttributeRenameVisitor.java
app-schema/app-schema/src/main/java/org/geotools/jdbc/NestedFilterToSQL.java
app-schema/app-schema/src/main/java/org/geotools/jdbc/WrappedFilterToSql.java
app-schema/app-schema/src/main/java/org/geotools/util/IndexQueryUtils.java
app-schema/app-schema/src/main/java/org/geotools/util/InterpolationProperties.java
app-schema/app-schema/src/main/java/org/geotools/util/XmlXpathUtilites.java
app-schema/app-schema/src/test/java/org/geotools/filter/BBoxTest.java
app-schema/app-schema/src/test/java/org/geotools/filter/expression/AppSchemaFeaturePropertyAccessorTest.java
app-schema/app-schema/src/test/java/org/geotools/filter/expression/FormatDateTimezoneFunctionTest.java
app-schema/app-schema/src/test/java/org/geotools/filter/GeometryFunctionsTest.java
app-schema/app-schema/src/test/java/org/geotools/filter/IDFunctionExpressionTest.java
app-schema/app-schema/src/test/java/org/geotools/filter/VocabFunctionsTest.java
app-schema/app-schema/src/test/java/org/geotools/test/AppSchemaTestSupport.java
app-schema/app-schema/src/test/java/org/geotools/util/ComplexAttributeConverterFactoryTest.java
app-schema/app-schema/src/test/java/org/geotools/util/IndexQueryUtilsTest.java
app-schema/app-schema/src/test/java/org/geotools/util/InterpolationPropertiesTest.java
app-schema/app-schema-resolver/src/main/java/org/geotools/xml/AppSchemaConfiguration.java
app-schema/app-schema-resolver/src/main/java/org/geotools/xml/AppSchemaLocationResolver.java
app-schema/app-schema-resolver/src/main/java/org/geotools/xml/AppSchemaValidator.java

[Geoserver-devel] JDK11: Yet Another Tuesday update

[Jim Hughes]

Hi all,

Today, I spent some time looking into the Stage 3 bits around split 
modules and the GeoTools repackaging.  I worked with the 
jsplitpkgscan[1] project a little bit to understand what it could tell us.


Jody and I iterated through a plan stage for the refactoring that needs 
to happen, and that work is in progress[2].  There are a number of 
choices being made and most of them are represented in his proposal to 
restructure GeoTools[3].  We've planned splitting up gt-api across 
different modules; that part seems ok.  As we've looked splitting up 
gt-main, there are additional considerations to work through.


Of note, Jody's looking to create a script that can be replayed via 
Eclipse to help migrate downstream projects to the new package names, etc.


Cheers,

Jim

1. https://github.com/AdoptOpenJDK/jsplitpkgscan
2. 
https://docs.google.com/spreadsheets/d/1oE6mU4jp-ZL5PebgXf-fuhtf7MY5dzSwPqpMtrzdZ94
3. 
https://github.com/geotools/geotools/wiki/Restructure-GeoTools-into-Jigsaw-modules





___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Measured geometries support in WFS

[Jim Hughes]

Hi Nuno, Andrea,

Good questions.  From my side, if we all agree on Jody's PR(1), then 
that should be most of the API changes.  I'd like to see the WK(B|K) 
readers and writers updated to handle Z and M.


In terms of time frame, are you trying to get this into GeoTools 
20/GeoServer 2.14?  (And when is that scheduled/expected?  September or 
later?  If so, we can identify a JTS release date that'd work.)


For expediting the JTS work, I'm looking for consensus and validation of 
the changes around Z and M.  In some sense, if Nuno's work builds off a 
JTS snapshot, I feel like that'd validate the JTS changes very well.   
For the WKB Reader/Writers, would that need to be in GeoTools to cover 
non-linear cases?  I'd love to see fewer classes called WKBReader, but I 
know that might not be possible;).


Cheers,

Jim

1. https://github.com/locationtech/jts/pull/293

On 07/31/2018 01:21 PM, Nuno Oliveira wrote:

My thoughts, thanks Andrea :)

On 07/31/2018 05:17 PM, Andrea Aime wrote:

Jody and James,
looks like a great opportunity for collaboration, but the vague 
timing has me worried.
Like, if the JTS stuff and consequent GeoTools upgrade happen one day 
before release, that leaves no time for Nuno to react.


I guess Nuno could work off snapshot JTS versions, how stable is the 
current API? Can we do anything to expedite

the JTS changes?

Cheers
Andrea
==

GeoServer Professional Services from the experts! Visit 
http://goo.gl/it488V for more information. == Ing. Andrea Aime 
@geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 
55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 
mob: +39 339 8844549 http://www.geo-solutions.it 
http://twitter.com/geosolutions_it 
--- /Con 
riferimento alla normativa sul trattamento dei dati personali (Reg. 
UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), 
si precisa che ogni circostanza inerente alla presente email (il suo 
contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza 
è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se 
il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni 
altra operazione è illecita. Le sarei comunque grato se potesse 
darmene notizia. This email is intended only for the person or entity 
to which it is addressed and may contain information that is 
privileged, confidential or otherwise protected from disclosure. We 
remind that - as provided by European Regulation 2016/679 “GDPR” - 
copying, dissemination or use of this e-mail or the information 
herein by anyone other than the intended recipient is prohibited. If 
you have received this email by mistake, please notify us immediately 
by telephone or e-mail./




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org!http://sdm.link/slashdot


___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


--
Regards,
Nuno Oliveira
==
GeoServer Professional Services from the experts!
Visithttp://goo.gl/it488V  for more information.
==

Nuno Miguel Carvalho Oliveira
@nmcoliveira
Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax:  +39 0584 1660272

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

---

Con riferimento alla normativa sul trattamento dei dati
personali (Reg. UE 2016/679 - Regolamento generale sulla
protezione dei dati “GDPR”), si precisa che ogni
circostanza inerente alla presente email (il suo contenuto,
gli eventuali allegati, etc.) è un dato la cui conoscenza
è riservata al/i solo/i destinatario/i indicati dallo
scrivente. Se il messaggio Le è giunto per errore, è
tenuta/o a cancellarlo, ogni altra operazione è illecita.
Le sarei comunque grato se potesse darmene notizia.

This email is intended only for the person or entity to
which it is addressed and may contain information that
is privileged, confidential or otherwise protected from
disclosure. We remind that - as provided by European
Regulation 2016/679 “GDPR” - copying, dissemination or
use of this e-mail or the information herein by anyone
other than the intended recipient is prohibited. If you
have received this email by mistake, please notify
us immediately by telephone or e-mail.


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Measured geometries support in WFS

[Jim Hughes]

Hi Nuno,

Quick question since it lines up with some of what Jody has been 
discussing...


Are you expecting to support more than one measure (i.e., multiple M's?) 
or just one?  (I'm biased since I'd only need one measure. Jody points 
to the other cases where users have a number of measures.)


Cheers,

Jim

On 07/31/2018 01:19 PM, Nuno Oliveira wrote:

Hi Andrea,
please see my answers bellow :)

On 07/31/2018 01:53 PM, Andrea Aime wrote:
I believe it would be nice/useful to have information about the M at 
the GeometryDescriptor level,

like done in this commit for the dimensions:
https://github.com/geotools/geotools/commit/a9c4b52c0404ec0357d0006ce8900c209875ec9a
but during a discussion you reported that the info is not always 
available and/or we might have

a mix of mesured and non measured geometries, could you elaborate?



Yes the goal is to have the information about the available 
measurements in the
user data of the geometry descriptor, similar to the dimension 
information [1],

is this aligned with what you were thinking ?

Data stores like PostGIS and shapefiles allow us to be explicit about 
the existence
of a measurement, e.g. using geometry types like PointM or 
LineStringM, so we
can infer the number of available measurements by looking at the 
meta-data,

but that may not be the case for all the other supported data stores ...

For the cases where is not possible to infer the number of 
measurements automatically
we will need to allow the user to provide it explicitly when 
configuring the layer. Note that
this may also be needed for use cases where the user was not explicit 
about the

geometry type.

For the moment I'm focusing \ supporting only the use cases where we 
can infer it automatically.


[1] 
https://github.com/geotools/geotools/blob/master/modules/library/jdbc/src/main/java/org/geotools/jdbc/JDBCFeatureSource.java#L330




On Tue, Jul 31, 2018 at 2:11 PM Nuno Oliveira 
> wrote:


   I ended up having CoordianteSequence.getDimension() as
described in the
conversation above, and
   CoordianteSequence.getMeasures() being the number of measures
(so if we have
XYZM dimension is 4 and measures is 1.


This would be a new method in a GeoTools "trait" interface that only 
some CoordinateSequences would

implement?


Yes, so basically when reading the geometry from the data source (e.g. 
PostGIS [2]) we will store the
information about the available measurements in the geometry user 
data, then we will use the new
getMeasures() utility method in the CoordianteSequence trait to get 
the information when needed, e.g.

when encoding the geometry to GML 3.2 [3].

[2] 
https://github.com/geotools/geotools/blob/master/modules/plugin/jdbc/jdbc-postgis/src/main/java/org/geotools/data/postgis/WKBReader.java#L181-L211 

[3] 
https://github.com/geotools/geotools/blob/master/modules/extension/xsd/xsd-gml2/src/main/java/org/geotools/gml2/simple/GMLWriter.java#L287-L301 



   1. correctly read geometries with measurements from data sources
   2. correctly encode the measurements in the output formats
   3. correctly handling measurements when doing certain
operations, e.g.
re-projections


Have a look here:
https://github.com/geotools/geotools/blob/9fbd02a320fa19d563972808d226a0a0445a5b13/modules/library/api/src/main/java/org/geotools/geometry/jts/DefaultCoordinateSequenceTransformer.java#L61


Ah yes the re-projections, I hope this class concentrates must of the 
code used to re-project the coordinates sequences ...



The following issue in GeoServer as an interesting discussion
about this:

https://osgeo-org.atlassian.net/browse/GEOS-8858


Yep, some output formats are allergic to M and we'd have to decide if 
to return it as a vendor extension (much like the way
we handle 2.5D data declaring a 2D CRS) and others allow loopholes 
but again not all clients might understand.


Ideally that configuration should be per layer basis, i.e. if M are 
available select all the output formats that should output it.
My main doubt is how to make that information reach the for example 
the GML encoder ... a thread local ? Alternatives here

are welcome :)


Cheers
Andrea

== GeoServer Professional Services from the experts! Visit 
http://goo.gl/it488V for more information. == Ing. Andrea Aime 
@geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 
55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 
mob: +39 339 8844549 http://www.geo-solutions.it 
http://twitter.com/geosolutions_it 
--- /Con 
riferimento alla normativa sul trattamento dei dati personali (Reg. 
UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), 
si precisa che ogni circostanza inerente alla presente email (il suo 
contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza 
è riservata al/i solo/i destinatario/i indicati dallo scrivente. 

Re: [Geoserver-devel] Measured geometries support in WFS

[Jim Hughes]

Hi Nuno,

First, I'm excited to see M measurements in WFS; I believe that's gonna 
be widely beneficial.


Second, for JTS, I can speak to the release schedule.  The library has 
traditionally been rather conservative/slow-to-release.  Over the 
summer, I visited Martin and Jody to sort out GeoTools/GeoServer 
upgrading to JTS 1.15.1.


Generally, my objective is that geometry storage and processing needs in 
GeoTools/GeoServer (and well, GeoMesa;)) could be handled in JTS and 
benefit everyone.  During our week, Jody, Martin, and I talked about 
support Z and M.  Jody started PR#293 out of that discussion, and I've 
separately have a branch to support TWKB (which doesn't work properly 
with Z and M yet).


For my part, if we can 'all agree' on the right changes to JTS, we can 
cut a JTS 1.16.0 as we like.  My opinion is that supporting Z and M with 
the CoordinateSequences and IO bits is the outstanding work to do for a 
1.16 release.


Cheers,

Jim

1. https://github.com/locationtech/jts/tree/twkb

On 07/31/2018 08:09 AM, Nuno Oliveira wrote:

Hi all,

I'm working on bringing support for M measurements in WFS. Some 
parallel work related with this is happening on JTS:


  * https://github.com/locationtech/jts/pull/293
  * https://github.com/locationtech/jts/pull/291

If I understood the JTS situation correctly, currently is already 
possible to store the M measurements values in
JTS geometries (XYZM or XYM), but is up to the client code to identify 
them and handle them. The main goal of the
changes above is to create a cleaner \ explicit JTS API, i.e. make it 
easier for client code to understand what
type of coordinates are available and make it easier to access the 
relevant ordinates.


I'm not aware of JTS release schedule, but I guess these changes will 
land on the next major release ? Which means
that they will not be available for us to use in GT\GS anytime soon. I 
would like to have the M support for WFS to
land on master before the next GeoServe 2.14.x release, i.e. it need 
to land on master next week at most.


Not using the new JTS API means that we will need to store the number 
of measures in the geometry user data.
This would be aligned with the new JTS API approach, quoting Jody 
comment on one of the pull request above:


  I ended up having CoordianteSequence.getDimension() as described in 
the conversation above, and
  CoordianteSequence.getMeasures() being the number of measures (so if 
we have XYZM dimension is 4 and measures is 1.


... so when the new JTS API becomes available we just need to switch 
to get the measures value from the JTS API

instead of the user data.

That said, supporting M measurements in WFS will require:

  1. correctly read geometries with measurements from data sources
  2. correctly encode the measurements in the output formats
  3. correctly handling measurements when doing certain operations, 
e.g. re-projections


The following issue in GeoServer as an interesting discussion about this:

  https://osgeo-org.atlassian.net/browse/GEOS-8858

Using PostGIS and GML 3.2. as an example:

  1. we will need to take into account the possibility of a 
measurement value when decoding geometries from postgis:
https://github.com/geotools/geotools/blob/master/modules/plugin/jdbc/jdbc-postgis/src/main/java/org/geotools/data/postgis/WKBReader.java#L194-L197 



  2. the correct geometry type (LINESTRINGM, LINESTRINGZM, etc ...) 
can be obtained from the database metadata


  3. vouch for the M measurement when encoding coordinates, e.g. 
linestring encoding for GML 3.2
https://github.com/geotools/geotools/blob/master/modules/extension/xsd/xsd-gml2/src/main/java/org/geotools/gml2/simple/GMLWriter.java#L287-L301 



In point 1 or 2 we will store in the user data the measurements number 
and use it in point 3.


Comments on this are welcome :)

Cheers,

Nuno Oliveira




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] JTS 1.15.0 upgrade planned shortly

[Jim Hughes]

Hi all,

For GeoFence, I have two branches which might help folks move forward:

For Hibernate-spatial, I have a fork and a branch here: 
https://github.com/jnh5y/hibernate-spatial1/tree/jts-1.15.1


From what I can gather, GeoFence uses this for H2 and Oracle Hibernate 
support.


A branch for GeoFence is here: 
https://github.com/jnh5y/geofence/tree/jts-1.15.1.  There seem to be 
some dependencies which should likely be upgrade to the later version of 
GeoTools.


I'm happy to try and help with those branches, but I think I'm at the 
edge of knowledge...


Cheers,

Jim

On 6/29/2018 6:57 PM, Jody Garnett wrote:

The following community modules are temporarily removed from the build:

- geogig
- script
- geofence
- geofence-server

--
Jody Garnett


On Fri, 29 Jun 2018 at 14:10, Jody Garnett > wrote:


Upgraded completed on geoserver master, ... and we have some
trouble with community modules.

Will report back shortly.
--
Jody Garnett


On Tue, 26 Jun 2018 at 13:09, Jody Garnett mailto:jody.garn...@gmail.com>> wrote:

Please see GeoTools proposal for details:
- https://github.com/geotools/geotools/wiki/Upgrade-to-JTS-1.15

The GeoServer details are here:
- https://osgeo-org.atlassian.net/browse/GEOS-8761
- https://github.com/jnh5y/geoserver/tree/jts-1.15.0

A formal PR is pending fixing a borehole test failure.
--
Jody Garnett



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] [Geotools-devel] JTS upgrade and Jaitools+Jai-ext

[Jim Hughes]

Hi Andrea,

Ok, I'm going to try and run down cutting an updated Jaitools release.

Cheers,

Jim

On 6/19/2018 2:05 PM, Andrea Aime wrote:

Hi Jim,
the long term path is the union of jaitools into jai-ext (at least 
parts of it). But it might take a while.
A short term release of JaiTools with newer JTS is ok imho, but you'll 
have to figure out how to release the thing onto some maven repo (does 
not need to be central), I personally have no clue how releases were 
done before.


Cheers
Andrea

On Tue, Jun 19, 2018 at 7:51 PM, Jim Hughes <mailto:jn...@ccri.com>> wrote:


Hi all,

Jody and I have been working on some of the background tasks to
upgrade GeoTools/GWC/GeoServer to JTS 1.15.0 (or later). We have a
proposal here
(https://github.com/geotools/geotools/wiki/Upgrade-to-JTS-1.15.0
<https://github.com/geotools/geotools/wiki/Upgrade-to-JTS-1.15.0>)
to track progress.

At the last GT/GS meeting, it was noted that Jaitools might need
to migrate into Jai-ext.  If we are indeed going to update the JTS
version, both of these projects would need to be updated and
released before GeoTools could be updated.

So, my question is:  What should the plan for Jaitools and Jai-Ext be?

* Should there be one 'last' Jaitools with JTS 1.15 released?

* Or should Jaitools be rolled into Jai-ext and then have the JTS
version bumped for the newer, greater Jai-extensions project?

I'm asking 'cause I'm going to be vacation-volunteering for
JTS+GeoTools work this Friday and all next week.  If we reach a
consensus, I'd be happy to run down some of this background legwork.

Cheers,

Jim



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
GeoTools-Devel mailing list
geotools-de...@lists.sourceforge.net
<mailto:geotools-de...@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/geotools-devel
<https://lists.sourceforge.net/lists/listinfo/geotools-devel>




--

Regards, Andrea Aime == GeoServer Professional Services from the 
experts! Visit http://goo.gl/it488V for more information. == Ing. 
Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di 
Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 
0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it 
http://twitter.com/geosolutions_it 
--- /Con 
riferimento alla normativa sul trattamento dei dati personali (Reg. UE 
2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si 
precisa che ogni circostanza inerente alla presente email (il suo 
contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è 
riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il 
messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra 
operazione è illecita. Le sarei comunque grato se potesse darmene 
notizia. This email is intended only for the person or entity to which 
it is addressed and may contain information that is privileged, 
confidential or otherwise protected from disclosure. We remind that - 
as provided by European Regulation 2016/679 “GDPR” - copying, 
dissemination or use of this e-mail or the information herein by 
anyone other than the intended recipient is prohibited. If you have 
received this email by mistake, please notify us immediately by 
telephone or e-mail./




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] JTS upgrade and Jaitools+Jai-ext

[Jim Hughes]

Hi all,

Jody and I have been working on some of the background tasks to upgrade 
GeoTools/GWC/GeoServer to JTS 1.15.0 (or later).  We have a proposal 
here (https://github.com/geotools/geotools/wiki/Upgrade-to-JTS-1.15.0) 
to track progress.


At the last GT/GS meeting, it was noted that Jaitools might need to 
migrate into Jai-ext.  If we are indeed going to update the JTS version, 
both of these projects would need to be updated and released before 
GeoTools could be updated.


So, my question is:  What should the plan for Jaitools and Jai-Ext be?

* Should there be one 'last' Jaitools with JTS 1.15 released?

* Or should Jaitools be rolled into Jai-ext and then have the JTS 
version bumped for the newer, greater Jai-extensions project?


I'm asking 'cause I'm going to be vacation-volunteering for JTS+GeoTools 
work this Friday and all next week.  If we reach a consensus, I'd be 
happy to run down some of this background legwork.


Cheers,

Jim


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Problems with the FeatureSizeFeatureCollection

[Jim Hughes]

Hi Andrea,

I tossed up a PR here: https://github.com/geoserver/geoserver/pull/2905 
with a ticket https://osgeo-org.atlassian.net/browse/GEOS-8779.


I am not seeing a quick way to provide a unit test.  If you (or anyone) 
has a suggestion on that front, I'm happy to include one.


Cheers,

Jim

On 06/08/2018 12:49 PM, Andrea Aime wrote:

Hi Jim,
yes, properly implemented collection wrappers should allow delegation

Cheers
Andrea

On Fri, Jun 8, 2018 at 6:47 PM, Jim Hughes <mailto:jhug...@ccri.com>> wrote:


Andrea,

Thanks for helping the PR through.

I haven't tested out the first case completely.  I've definitely
run into the issue that Alvaro is trying to address with WFS 2.0.

In the short term, is allowing the FC to delegate reasonable?

Cheers,

Jim


On 06/08/2018 12:07 PM, Andrea Aime wrote:

Ah,
that change was controversial and the pull request sat there for
ages before being merged:
https://github.com/geoserver/geoserver/pull/2664
<https://github.com/geoserver/geoserver/pull/2664>

(shows me as the author, but it's not really me, I'm just
unwillingly involved because nobody else would take action)

Please discuss.

Cheers
Andrea


On Fri, Jun 8, 2018 at 5:57 PM, Jim Hughes mailto:jhug...@ccri.com>> wrote:

Hi all,

While testing out GeoMesa with GeoServer 2.13.x, we ran into
some issues with the FeatureSizeFeatureCollection.  I think
there are two issues:

First, for a layers backed by a large volume of data,
getCount returning -1 is partially a way of saying that you
don't want to count all the features;).  Given this pattern,
I'd suggest that the FeatureSizeFeatureCollection might be
taken off the usual path completely.  It looks like it might
be an optimization when working with a bunch of little
shapefiles.

Second, WPSes can be implemented with a visitor pattern.  For
instance, the gs:Unique process leverages the GeoTools
UniqueVisitor(1) which is recognized by the JDBC DataStores. 
(In GeoMesa, we do a bunch of similar things.)

The fact that the current FeatureSizeFeatureCollection
doesn't delegate prevents the UniqueProcess (and the GeoMesa
ones) from working properly...

In the short term, any objection to a PR which enables
delegation for that FeatureCollection?

Cheers,

Jim

1. UniqueVisitor:

https://github.com/geotools/geotools/blob/master/modules/library/main/src/main/java/org/geotools/feature/visitor/UniqueVisitor.java

<https://github.com/geotools/geotools/blob/master/modules/library/main/src/main/java/org/geotools/feature/visitor/UniqueVisitor.java>


https://github.com/geotools/geotools/blob/master/modules/library/jdbc/src/main/java/org/geotools/jdbc/SQLDialect.java#L375

<https://github.com/geotools/geotools/blob/master/modules/library/jdbc/src/main/java/org/geotools/jdbc/SQLDialect.java#L375>


p.s.  I debugged this using PostGIS and the gs:Unique
process. When the FeatureSizeFC was 'on', the queries did not
have the 'distinct' keyword.  When the FC was off, GeoServer
did make a 'distinct' query.



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
<mailto:Geoserver-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
<https://lists.sourceforge.net/lists/listinfo/geoserver-devel>




-- 


Regards, Andrea Aime == GeoServer Professional Services from the
experts! Visit http://goo.gl/it488V for more information. == Ing.
Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di
Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax:
+39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it
http://twitter.com/geosolutions_it
<http://twitter.com/geosolutions_it>
--- /Con
riferimento alla normativa sul trattamento dei dati personali
(Reg. UE 2016/679 - Regolamento generale sulla protezione dei
dati “GDPR”), si precisa che ogni circostanza inerente alla
presente email (il suo contenuto, gli eventuali allegati, etc.) è
un dato la cui conoscenza è riservata al/i solo/i destinatario/i
indicati dallo scrivente. Se il messaggio Le è giunto per errore,
è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
sarei comunque grato se potesse darmene notizia. This email is
intended only for the pe

[Geoserver-devel] Problems with the FeatureSizeFeatureCollection

[Jim Hughes]

Hi all,

While testing out GeoMesa with GeoServer 2.13.x, we ran into some issues 
with the FeatureSizeFeatureCollection.  I think there are two issues:


First, for a layers backed by a large volume of data, getCount returning 
-1 is partially a way of saying that you don't want to count all the 
features;).  Given this pattern, I'd suggest that the 
FeatureSizeFeatureCollection might be taken off the usual path 
completely.  It looks like it might be an optimization when working with 
a bunch of little shapefiles.


Second, WPSes can be implemented with a visitor pattern.  For instance, 
the gs:Unique process leverages the GeoTools UniqueVisitor(1) which is 
recognized by the JDBC DataStores.  (In GeoMesa, we do a bunch of 
similar things.)


The fact that the current FeatureSizeFeatureCollection doesn't delegate 
prevents the UniqueProcess (and the GeoMesa ones) from working properly...


In the short term, any objection to a PR which enables delegation for 
that FeatureCollection?


Cheers,

Jim

1. UniqueVisitor: 
https://github.com/geotools/geotools/blob/master/modules/library/main/src/main/java/org/geotools/feature/visitor/UniqueVisitor.java 

https://github.com/geotools/geotools/blob/master/modules/library/jdbc/src/main/java/org/geotools/jdbc/SQLDialect.java#L375 



p.s.  I debugged this using PostGIS and the gs:Unique process. When the 
FeatureSizeFC was 'on', the queries did not have the 'distinct' 
keyword.  When the FC was off, GeoServer did make a 'distinct' query.


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Should we try sudo enabled images in build?

[Jim Hughes]

NB:  Trying the sudo enabled one is cheap since Travis automatically 
builds branches*.  For GeoMesa, we've had various Travis issues, and we 
fooled around with branches to try out various things.  Using the 
sudo-enabled boxes definitely helped...


After that... we found that tweaking Maven+memory parameters and pulling 
other tricks helped.


*https://travis-ci.org/geoserver/geoserver/branches

On 06/04/2018 04:56 AM, Nuno Oliveira wrote:

+1

On 06/03/2018 08:00 AM, Andrea Aime wrote:

Hi,
as far as  I can tell there is a number of build failures on Travis 
that are file system related, and others
that might be related to concurrent load in the build environment 
(just a guess).

Build have just not been very reliable lately.

I was checking our options and found this table:
https://docs.travis-ci.com/user/reference/overview/#Virtualisation-Environment-vs-Operating-System

We are on the container based trusty environment right now. I was 
wondering, has anyone tried already

the sudo enabled one instead?
As far as I can tell from the table, it would give us more memory, 
more disk space, a "real" file system
instead of a user space one, at the price of higher startup time and 
probably less CPU available.


Worth a try, to see if we can get more stable builds?

Cheers
Andrea

== GeoServer Professional Services from the experts! Visit 
http://goo.gl/it488V for more information. == Ing. Andrea Aime 
@geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 
55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 
mob: +39 339 8844549 http://www.geo-solutions.it 
http://twitter.com/geosolutions_it 
--- /Con 
riferimento alla normativa sul trattamento dei dati personali (Reg. 
UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), 
si precisa che ogni circostanza inerente alla presente email (il suo 
contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza 
è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se 
il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni 
altra operazione è illecita. Le sarei comunque grato se potesse 
darmene notizia. This email is intended only for the person or entity 
to which it is addressed and may contain information that is 
privileged, confidential or otherwise protected from disclosure. We 
remind that - as provided by European Regulation 2016/679 “GDPR” - 
copying, dissemination or use of this e-mail or the information 
herein by anyone other than the intended recipient is prohibited. If 
you have received this email by mistake, please notify us immediately 
by telephone or e-mail./




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org!http://sdm.link/slashdot


___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


--
Regards,
Nuno Oliveira
==
GeoServer Professional Services from the experts!
Visithttp://goo.gl/it488V  for more information.
==

Nuno Miguel Carvalho Oliveira
@nmcoliveira
Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax:  +39 0584 1660272

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

---

Con riferimento alla normativa sul trattamento dei dati
personali (Reg. UE 2016/679 - Regolamento generale sulla
protezione dei dati “GDPR”), si precisa che ogni
circostanza inerente alla presente email (il suo contenuto,
gli eventuali allegati, etc.) è un dato la cui conoscenza
è riservata al/i solo/i destinatario/i indicati dallo
scrivente. Se il messaggio Le è giunto per errore, è
tenuta/o a cancellarlo, ogni altra operazione è illecita.
Le sarei comunque grato se potesse darmene notizia.

This email is intended only for the person or entity to
which it is addressed and may contain information that
is privileged, confidential or otherwise protected from
disclosure. We remind that - as provided by European
Regulation 2016/679 “GDPR” - copying, dissemination or
use of this e-mail or the information herein by anyone
other than the intended recipient is prohibited. If you
have received this email by mistake, please notify
us immediately by telephone or e-mail.


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel



--
Check out the vibrant tech community on one 

Re: [Geoserver-devel] How to apply CQL Filter on FeatureType Property that contains Json Object

[Jim Hughes]

Hi all,

We did something like Nuno's first suggestion in GeoMesa:

https://github.com/locationtech/geomesa/blob/master/geomesa-features/geomesa-feature-kryo/src/main/scala/org/locationtech/geomesa/features/kryo/json/JsonPathFilterFunction.scala

https://github.com/locationtech/geomesa/blob/master/geomesa-features/geomesa-feature-kryo/src/test/scala/org/locationtech/geomesa/features/kryo/json/JsonPathFilterFunctionTest.scala

In the short term, one may be able to drop in the geomesa-feature-kryo 
jar (with enough dependencies) to make things work.


Cheers,

Jim


On 03/20/2018 04:57 PM, Nuno Oliveira wrote:

Hi,

As far as I know filtering with CQL\OGC Filter\ECQL on the JSON 
content of a property is not possible, for GeoServer the EntityUser 
value is just a normal String.


I can see two paths for this:

  * Implement a custom function that would help you dealing with JSON
and then use it in the CQL filter

  o for example a function that given a certain path extract the
correspond value from JSON

  * create a view, a real view in the database or a GeoServer view,
that would put the content of the

Hope it helps,

Nuno Oliveira

On 03/20/2018 04:20 AM, C.Ram wrote:

I have mssql datastore and named layer Compressor generated based on SQL view
query that I want to filter from Openlayer wms request based on Property
EntityUser that contains JSON object with a key.

Sample JSON that contains EntityUser Column/Property is:
 
   {

 "4742ed9e-384c-41fe-9240-8ced1da67759": {
 "242b5425-2abb-45f1-8f6f-e962ef0861e0":
["746c8188-0125-41f5-aa61-e42c753a77ac"]
 },
 "fff4f98e-cddd-4c7e-aa3e-57e20ec682e9": {
 "242b5425-2abb-45f1-8f6f-e962ef0861e0":
["746c8188-0125-41f5-aa61-e42c753a77ac"]
 }
 }


So how I apply cql or ogc filter on Property that having JSONObject?

Layer Preview Image:
  


And also suggest what are all the way possible to filter layer.



--
Sent from:http://osgeo-org.1560.x6.nabble.com/GeoServer-Dev-f3819232.html

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org!http://sdm.link/slashdot
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel



--
Regards,
Nuno Oliveira
==
GeoServer Professional Services from the experts! Visithttp://goo.gl/it488V  
for more information.
==

Nuno Miguel Carvalho Oliveira
@nmcoliveira
Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax:  +39 0584 1660272

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

---
AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i 
file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo 
è consentito esclusivamente al destinatario del messaggio, per le finalità 
indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne 
il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di 
procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro 
sistema. Conservare il messaggio stesso, divulgarlo anche in parte, 
distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, 
costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.
  
The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility  for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


___
Geoserver-devel 

Re: [Geoserver-devel] Travis build keeps failing

[Jim Hughes]

Hi all,

Repo issues aside, for GeoMesa, we were seeing slow builds on Travis.  
One thing which sped things up a little bit was to use the experimental 
newer Ubuntu version with lines like this in .travis.yml:


sudo: required
dist: trusty

That might help with the actual compile/test speeds...

Cheers,

Jim

On 07/07/2017 12:24 PM, Torben Barsballe wrote:
I've had the same issue, and I've been seeing this happen more 
frequently recently.


Torben

On Fri, Jul 7, 2017 at 9:08 AM, Daniele Romagnoli 
> wrote:


Hi,
btw, yesterday I had to restart a travis build a couple of time
due to the job exceeding timeout :)



On Tue, Jul 4, 2017 at 10:14 AM, Nuno Oliveira
> wrote:

It may be, well Travis seems to be happy again :)


On 07/04/2017 08:55 AM, Andrea Aime wrote:

Hi,
I have seen builds fail due to the maven repository being
very slow to respond.
And then, out of the blue some times later, it becomes fast
again and builds go.

Cheers
Andrea


On Mon, Jul 3, 2017 at 10:35 PM, Nuno Oliveira
> wrote:

Help after trying several times the build just start
passing again.
I still have no idea what happen.


On 07/03/2017 01:43 PM, Nuno Oliveira wrote:

Hi,

I made a change on this PR
https://github.com/geoserver/geoserver/pull/2450

fixing a comment typo
and since then the Travis build keeps failing:
https://api.travis-ci.org/jobs/249523821/log.txt?deansi=true


It seems that Travis is crashing because of some timeout:

uploading archive
running `casher push` took longer than 180 seconds
and has been aborted

I'm not sure what is going on, did anyone already
experience something similar ?

Regards,


-- 
Regards,

Nuno Oliveira
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==

Nuno Miguel Carvalho Oliveira
@nmcoliveira
Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
Italy
phone: +39 0584 962313 
fax: +39 0584 1660272 

http://www.geo-solutions.it
http://twitter.com/geosolutions_it


---
AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
Le informazioni contenute in questo messaggio di posta
elettronica e/o nel/i file/s allegato/i sono da
considerarsi strettamente riservate. Il loro utilizzo è
consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora
riceviate questo messaggio senza esserne il destinatario,
Vi preghiamo cortesemente di darcene notizia via e-mail e
di procedere alla distruzione del messaggio stesso,
cancellandolo dal Vostro sistema. Conservare il messaggio
stesso, divulgarlo anche in parte, distribuirlo ad altri
soggetti, copiarlo, od utilizzarlo per finalità diverse,
costituisce comportamento contrario ai principi dettati
dal D.Lgs. 196/2003.
 The information in this message and/or attachments, is
intended solely for the attention and use of the named
addressee(s) and may be confidential or proprietary in
nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New
Data Protection Code).Any use not in accord with its
purpose, any disclosure, reproduction, copying,
distribution, or either dissemination, either whole or
partial, is strictly forbidden except previous formal
approval of the named addressee(s). If you are not the
intended recipient, please contact immediately the sender
by telephone, fax or e-mail and delete the information in
this message that has been received in error. The sender
does not give any warranty or accept liability as the
content, accuracy or 

Re: [Geoserver-devel] proposed change: coverage readers custom dimension data type conversion

[Jim Hughes]

Hi all,

Sorry I missed this until now.  I'm not following too closely, but it 
sounds like this is an improvement.  If it requires a slight update to 
any Coverage Readers, we can sort things out.


Cheers,

Jim

On 03/22/2017 09:56 AM, Andrea Aime wrote:

Hi Niels,
there is one test about custom dimensions treatment that was 
contributed by Mike Benowitz years ago, I've
cc'ed him along with another fellow at GDIT, they might be affected 
(or not).
I also know GeoMesa has their own custom readers, no idea if they are 
dimension enabled or not. Cc'ed Jim just in case.


Cheers
Andrea


On Wed, Mar 22, 2017 at 2:27 PM, Niels Charlier > wrote:


Hello,

This message is particularly aimed at people who develop/use coverage
readers that support custom dimensions, but are outside of the main
geotools/geoserver code base.

I am proposing a change that may affect them (see
https://osgeo-org.atlassian.net/browse/GEOS-7989
). In short:

At this moment Coverage Reader may or may not advertise a Java class
through their metadata for each custom dimension.

However, geoserver WMS and WCS1 ignore this and always put custom
dimension values in String format inside the query filter. My PR would
change this and attempt to convert to the advertised type first, if
possible.

The only affected readers in the official code base are netcdf and
imagemosaic. My change would break neither, but rather improve
both (by
supporting Dates). However, it is possible that there are other
readers
around that advertise a class but still assume a String in the query
(because that is how it works now).

So if that is the case, please respond to this message.

In general, I would like to know whether this change is OK with the
community.

Kind Regards

Niels



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/geoserver-devel





--
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o 
nel/i file/s allegato/i sono da considerarsi strettamente riservate. 
Il loro utilizzo è consentito esclusivamente al destinatario del 
messaggio, per le finalità indicate nel messaggio stesso. Qualora 
riceviate questo messaggio senza esserne il destinatario, Vi preghiamo 
cortesemente di darcene notizia via e-mail e di procedere alla 
distruzione del messaggio stesso, cancellandolo dal Vostro sistema. 
Conservare il messaggio stesso, divulgarlo anche in parte, 
distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità 
diverse, costituisce comportamento contrario ai principi dettati dal 
D.Lgs. 196/2003.


The information in this message and/or attachments, is intended solely 
for the attention and use of the named addressee(s) and may be 
confidential or proprietary in nature or covered by the provisions of 
privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New 
Data Protection Code).Any use not in accord with its purpose, any 
disclosure, reproduction, copying, distribution, or either 
dissemination, either whole or partial, is strictly forbidden except 
previous formal approval of the named addressee(s). If you are not the 
intended recipient, please contact immediately the sender by 
telephone, fax or e-mail and delete the information in this message 
that has been received in error. The sender does not give any warranty 
or accept liability as the content, accuracy or completeness of sent 
messages and accepts no responsibility  for changes made after they 
were sent or for other risks which arise as a result of e-mail 
transmission, viruses, etc.



---



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] WPS S3 Artifact Plugin

[Jim Hughes]

Hi Craig,

I'd second that.  This with some recent improvements to GeoServer 
start-up order and maybe other S3-related stores coming up, there could 
be some exciting possibilities!

Cheers,

Jim

On 03/28/2017 01:31 PM, Simone Giannecchini wrote:
> Dear Craig,
> I would think that this could be a useful community module to have.
> Same goes for your feedback.
>
> The procedure to follow is here (it should be pretty relaxed):
> http://docs.geoserver.org/stable/en/developer/policies/community-modules.html#creating-a-community-module
>
>
> Regards,
> Simone Giannecchini
> ==
> GeoServer Professional Services from the experts!
> Visit http://goo.gl/it488V for more information.
> ==
> Ing. Simone Giannecchini
> @simogeo
> Founder/Director
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob:   +39  333 8128928
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> ---
> AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate.
> Il loro utilizzo è consentito esclusivamente al destinatario del
> messaggio, per le finalità indicate nel messaggio stesso. Qualora
> riceviate questo messaggio senza esserne il destinatario, Vi preghiamo
> cortesemente di darcene notizia via e-mail e di procedere alla
> distruzione del messaggio stesso, cancellandolo dal Vostro sistema.
> Conservare il messaggio stesso, divulgarlo anche in parte,
> distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità
> diverse, costituisce comportamento contrario ai principi dettati dal
> D.Lgs. 196/2003.
>
> The information in this message and/or attachments, is intended solely
> for the attention and use of the named addressee(s) and may be
> confidential or proprietary in nature or covered by the provisions of
> privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New
> Data Protection Code).Any use not in accord with its purpose, any
> disclosure, reproduction, copying, distribution, or either
> dissemination, either whole or partial, is strictly forbidden except
> previous formal approval of the named addressee(s). If you are not the
> intended recipient, please contact immediately the sender by
> telephone, fax or e-mail and delete the information in this message
> that has been received in error. The sender does not give any warranty
> or accept liability as the content, accuracy or completeness of sent
> messages and accepts no responsibility  for changes made after they
> were sent or for other risks which arise as a result of e-mail
> transmission, viruses, etc.
>
>
> On Tue, Mar 28, 2017 at 8:33 AM, Craig Jones  wrote:
>> Hi All,
>>
>> We've developed a geoserver plugin we use to store WPS output artifacts
>> on AWS S3 and I'm wondering if this may be considered useful by other
>> members of the community/whether it could be included as a community plugin.
>>
>> The source code for the plugin can be found at
>> https://github.com/aodn/geoserver/tree/2.8.4-imos/src/community/wps-s3-artifacts
>>
>> The plugin implements the ProcessArtifactsStore interface which looked
>> like it was provided for this purpose.
>>
>> With this plugin installed, temporary resources are sourced from a local
>> file system store and process outputs are streamed to s3.
>>
>> If this sounds useful I'm happy to provide any other details required
>> and some feedback on issues I encountered using ProcessArtifactsStore.
>>
>>
>> Thanks,
>>
>> Craig Jones
>>
>> Australian Ocean Data Network
>>
>> Integrated Marine Observing system
>>
>>
>>
>>
>>
>>
>> University of Tasmania Electronic Communications Policy (December, 2014).
>> This email is confidential, and is for the intended recipient only. Access, 
>> disclosure, copying, distribution, or reliance on any of it by anyone 
>> outside the intended recipient organisation is prohibited and may be a 
>> criminal offence. Please delete if obtained in error and email confirmation 
>> to the sender. The views expressed in this email are not necessarily the 
>> views of the University of Tasmania, unless clearly intended otherwise.
>>
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> Geoserver-devel mailing list
>> Geoserver-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> 

Re: [Geoserver-devel] Time dimension on Vector Layer is SLOW

[Jim Hughes]

On 01/24/2017 02:27 AM, Andrea Aime wrote:
On Tue, Jan 24, 2017 at 1:28 AM, Dave Blasby > wrote:


For the get capabilities (layer Time dimension set to LIST and
default=max value) you will see two queries;
1. unique visitor (Postgis: SELECT DISTINCT ...) to get the LIST
of values
2. max visitor (Postgis: SELECT max ...) to get the default value

For most datasets (i.e. non-database), this will be 2 full scans
of the dataset.


Hum... that's debatable imho, only dumb datasets are really forced 
into full scans.
Shapefile certainly cannot optimize out the visitors, but other data 
stores

could if code was added to them.
E.g., SOLR and Mongo can both execute max visitor fast, but there is 
no optimized implementation in the store.
What's annoying is that there is no way to know if a store can 
optimize these operations.


Since these calls are part of GetCapabilities, would it make sense to 
add some handling to the DataStore API / ContentDataStore abstract 
implementation (or worst case, the docs)?


With a change like that, it might make it easier for developers (both 
implementing and reading/understanding) to see what is going on.  The 
default abstract implementation could have some safe guards in place to 
prevent full-table scans.


Thoughts?

Jim

That said, time based data requires a index to operate efficiently 
(all request will hit a specific
time or time range) so... well... you definitely don't want to run it 
off a shapefile or other
non indexed source. And if there is an index, both those operations 
should be easy to optimize

(given developer time).

About static vs dynamic, both have their own use case, what we have 
today in GeoServer
is the case that sponsored the original functionality (e.g. data 
mostly static from the spatial
p.o.v. and changing quite aggressively on the temporal p.o.v.), full 
dynamic bboxes
and cached/configured dimensions values both make sense and their 
support could

be created given enough development resources.

Cheers
Andrea
--
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o 
nel/i file/s allegato/i sono da considerarsi strettamente riservate. 
Il loro utilizzo è consentito esclusivamente al destinatario del 
messaggio, per le finalità indicate nel messaggio stesso. Qualora 
riceviate questo messaggio senza esserne il destinatario, Vi preghiamo 
cortesemente di darcene notizia via e-mail e di procedere alla 
distruzione del messaggio stesso, cancellandolo dal Vostro sistema. 
Conservare il messaggio stesso, divulgarlo anche in parte, 
distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità 
diverse, costituisce comportamento contrario ai principi dettati dal 
D.Lgs. 196/2003.


The information in this message and/or attachments, is intended solely 
for the attention and use of the named addressee(s) and may be 
confidential or proprietary in nature or covered by the provisions of 
privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New 
Data Protection Code).Any use not in accord with its purpose, any 
disclosure, reproduction, copying, distribution, or either 
dissemination, either whole or partial, is strictly forbidden except 
previous formal approval of the named addressee(s). If you are not the 
intended recipient, please contact immediately the sender by 
telephone, fax or e-mail and delete the information in this message 
that has been received in error. The sender does not give any warranty 
or accept liability as the content, accuracy or completeness of sent 
messages and accepts no responsibility  for changes made after they 
were sent or for other risks which arise as a result of e-mail 
transmission, viruses, etc.



---


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot


___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Show 45 Millions of data : HeatMap or Clustering

[Jim Hughes]

Hi Jeoffrey,

We have tweaked the heatmap process for use with GeoMesa; the process 
can be changed to pass query hints which a GeoTools datastore can 
leverage to execute the query differently.  As an example of setting the 
hints in the process, see [1].  Those query hints are picked up by the 
GeoMesa query planner, and the computation of the heatmap can be 
distributed to the Accumulo tablet servers.  Instead of returning 
SimpleFeatures, a grid of inputs to the HeatmapSurface is computed by 
the DataStore.


Anyhow, I mention that as an example of tweaking a WPS process a little 
bit; there is some effort at the DataStore level as well... And I'm not 
sure what could be done in PostGIS; there may be something clever to do 
there.


As a back-of-the-envelope, for GeoMesa, I've typically seen a few 
hundred thousand records stream back to GeoServer per second.  As a gut 
feeling, I'd say that the optimization for a heatmap speeds things up 
around 10-25%...  Even with that, for a query returning 45 million 
records, it could take longer than 60 seconds for that many records to 
come back.  The usual rendering timeout is set to 60 seconds, so 
requests could be dying there.


Cheers,

Jim

1. 
https://github.com/locationtech/geomesa/blob/master/geomesa-process/src/main/scala/org/locationtech/geomesa/process/DensityProcess.scala#L115-L123


On 11/29/2016 09:35 AM, Andrea Aime wrote:

Hi,
I'm not the author of those processes so I can only provide limited 
help, but I'm wondering
do you really want to transfer that many points between PostGIS and 
GeoServer?
I would look for a way to do clustering directly in the database, and 
get out directly

the synthetic information instead.

Maybe using a SQL view, for example. This stackoverflow entry might be 
of help:

http://gis.stackexchange.com/questions/11567/spatial-clustering-with-postgis

Cheers
Andrea



On Tue, Nov 29, 2016 at 9:52 AM, jarjar > wrote:


Hi everybody,

For my work, I have to be able to propose by wms a representation
of 45
million point data (position).
For the moment, I use the Heatmap and Clustering representations,
proposed
on different forums, and calculated using the WPS module. Beyond
16 million
features, geoserver no longer responds, or it takes a lot of time.
Do you ever encounter this problem? If so how then? Can I multi-thread
treatments?
Moreover, looking at the logs, I have the impression that
geoserver requests
3 times the selection of the elements in database, why?
thank you for everything



--
View this message in context:

http://osgeo-org.1560.x6.nabble.com/Show-45-Millions-of-data-HeatMap-or-Clustering-tp5297803.html


Sent from the GeoServer - Dev mailing list archive at Nabble.com.


--
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/geoserver-devel





--
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o 
nel/i file/s allegato/i sono da considerarsi strettamente riservate. 
Il loro utilizzo è consentito esclusivamente al destinatario del 
messaggio, per le finalità indicate nel messaggio stesso. Qualora 
riceviate questo messaggio senza esserne il destinatario, Vi preghiamo 
cortesemente di darcene notizia via e-mail e di procedere alla 
distruzione del messaggio stesso, cancellandolo dal Vostro sistema. 
Conservare il messaggio stesso, divulgarlo anche in parte, 
distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità 
diverse, costituisce comportamento contrario ai principi dettati dal 
D.Lgs. 196/2003.


The information in this message and/or attachments, is intended solely 
for the attention and use of the named addressee(s) and may be 
confidential or proprietary in nature or covered by the provisions of 
privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New 
Data Protection Code).Any use not in accord with its purpose, any 
disclosure, reproduction, copying, distribution, or either 
dissemination, either whole or partial, is strictly forbidden except 
previous formal approval of the named addressee(s). If you are not the 

Re: [Geoserver-devel] [Geoserver-users] [Geotools-devel] Call for Online MiniSprint

[Jim Hughes]

Hi all,

I'd like to participate as well; maybe you can kick a few of the easy 
tasks my way.

Cheers,

Jim

On 7/11/2016 7:15 PM, Ben Caradoc-Davies wrote:
> Count me in!
>
> Kind regards,
> Ben.
>
> On 12/07/16 10:28, Jody Garnett wrote:
>> I tomorrows meeting I would like to firmly establish July 22nd as our
>> intended date for this (or establish an alternate if the above does not
>> work out).
>>
>> In anticipation, how is everyone's availability for July 22nd?
>>
>> --
>> Jody Garnett
>>
>> On 6 July 2016 at 12:04, Jody Garnett  wrote:
>>
>>> My +1 for July 22nd.
>>>
>>> Hard to schedule a monthly "bug rodeo" at the end of the month.
>>>
>>> As per meeting discussion It may be helpful to have a couple volunteers to
>>> prep the day before so we can be effective on July 22nd.
>>>
>>> --
>>> Jody Garnett
>>>
>>> On 6 July 2016 at 08:16, Simone Giannecchini <
>>> simone.giannecch...@geo-solutions.it> wrote:
>>>
 Dear All,
 sorry for cross posting but I believe this is something that might
 impact both users as well as developers of GetoTools and GeoServer.

 I wanted to propose an online, distributed, loosely coordinated 1 day
 sprint in the short term where people can help GeoServer as well as
 GeoTools with things like:
 - reviewing open JIRA
 - fixing bugs
 - improving documentation
 - doing testing and so on
 - cheering the others up

 Coordination could be as simple as a google spreadsheet where people
 can log what they are working on + an hangout to chat if/as needed.
 This could become a recurrent event, like one a month in the future.
 The goal is not to develop new features but to improve quality of code
 and documentation.

 Right now I have in mind two dates:
 - 22nd of July
 - 29th of July

 We at GeoSolutions are happy with both dates and we will do this
 anyway, to get the ball rolling.

 Looking forward to reading your feedback. I might move this email over
 to a post on the GeoServer blog to gain more attention.

 Regards,
 Simone Giannecchini
 ==
 GeoServer Professional Services from the experts!
 Visit http://goo.gl/it488V for more information.
 ==
 Ing. Simone Giannecchini
 @simogeo
 Founder/Director

 GeoSolutions S.A.S.
 Via di Montramito 3/A
 55054  Massarosa (LU)
 Italy
 phone: +39 0584 962313
 fax: +39 0584 1660272
 mob:   +39 333 8128928

 http://www.geo-solutions.it
 http://twitter.com/geosolutions_it

 ---
 AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
 Le informazioni contenute in questo messaggio di posta elettronica e/o
 nel/i file/s allegato/i sono da considerarsi strettamente riservate.
 Il loro utilizzo è consentito esclusivamente al destinatario del
 messaggio, per le finalità indicate nel messaggio stesso. Qualora
 riceviate questo messaggio senza esserne il destinatario, Vi preghiamo
 cortesemente di darcene notizia via e-mail e di procedere alla
 distruzione del messaggio stesso, cancellandolo dal Vostro sistema.
 Conservare il messaggio stesso, divulgarlo anche in parte,
 distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità
 diverse, costituisce comportamento contrario ai principi dettati dal
 D.Lgs. 196/2003.

 The information in this message and/or attachments, is intended solely
 for the attention and use of the named addressee(s) and may be
 confidential or proprietary in nature or covered by the provisions of
 privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New
 Data Protection Code).Any use not in accord with its purpose, any
 disclosure, reproduction, copying, distribution, or either
 dissemination, either whole or partial, is strictly forbidden except
 previous formal approval of the named addressee(s). If you are not the
 intended recipient, please contact immediately the sender by
 telephone, fax or e-mail and delete the information in this message
 that has been received in error. The sender does not give any warranty
 or accept liability as the content, accuracy or completeness of sent
 messages and accepts no responsibility  for changes made after they
 were sent or for other risks which arise as a result of e-mail
 transmission, viruses, etc.


 --
 Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
 Francisco, CA to explore cutting-edge tech and listen to tech luminaries
 present their vision of the future. This family event has something for
 everyone, including kids. Get more information and register today.
 http://sdm.link/attshape
 ___
 GeoTools-Devel 

Re: [Geoserver-devel] GeoServer Style page improvements

[Jim Hughes]

On 07/11/2016 05:17 PM, Jody Garnett wrote:
> For the map preview, is it worth adding a base map of some form to 
> provide context?

Big +1 for adding some configurable basemaps for context.  In some 
contexts, being able to point to your own basemap might be groovy...

Cheers,

Jim

--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Module status GSIP still in "design and discussion"?

[Jim Hughes]

Hi Dave,

As a quick question, are the status pages going into master only or are 
they getting backported to the 2.9.x series?

Cheers,

Jim

On 07/11/2016 01:26 PM, Dave Blasby wrote:
> Hi, Andrea,
>
> I've been adding status pages for various modules (mostly ones
> involving native dependencies) - torben has been reviewing them.   The
> status pages have been very useful in debugging install issues.
>
> I've moved it down from "discuss" to "active."  Not sure if others are
> working on it...
>
> Thanks,
> dave
>
> On Sat, Jul 9, 2016 at 2:35 AM, Andrea Aime
>  wrote:
>> Hi,
>> I see that the module status GSIP is still listed under "design and
>> discussion"... looks to
>> me like it's either active or completed instead, but I could be wrong.
>>
>> https://github.com/geoserver/geoserver/wiki/Proposals
>> https://github.com/geoserver/geoserver/wiki/GSIP-143
>>
>> Can responsible parties update the proposal page?
>>
>> Cheers
>> Andrea
>>
>> --
>> ==
>> GeoServer Professional Services from the experts! Visit
>> http://goo.gl/it488V for more information.
>> ==
>>
>> Ing. Andrea Aime
>> @geowolf
>> Technical Lead
>>
>> GeoSolutions S.A.S.
>> Via di Montramito 3/A
>> 55054  Massarosa (LU)
>> phone: +39 0584 962313
>> fax: +39 0584 1660272
>> mob: +39  339 8844549
>>
>> http://www.geo-solutions.it
>> http://twitter.com/geosolutions_it
>>
>> AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
>>
>> Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i
>> file/s allegato/i sono da considerarsi strettamente riservate. Il loro
>> utilizzo è consentito esclusivamente al destinatario del messaggio, per le
>> finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio
>> senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia
>> via e-mail e di procedere alla distruzione del messaggio stesso,
>> cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo
>> anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per
>> finalità diverse, costituisce comportamento contrario ai principi dettati
>> dal D.Lgs. 196/2003.
>>
>>
>>
>> The information in this message and/or attachments, is intended solely for
>> the attention and use of the named addressee(s) and may be confidential or
>> proprietary in nature or covered by the provisions of privacy act
>> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
>> Code).Any use not in accord with its purpose, any disclosure, reproduction,
>> copying, distribution, or either dissemination, either whole or partial, is
>> strictly forbidden except previous formal approval of the named
>> addressee(s). If you are not the intended recipient, please contact
>> immediately the sender by telephone, fax or e-mail and delete the
>> information in this message that has been received in error. The sender does
>> not give any warranty or accept liability as the content, accuracy or
>> completeness of sent messages and accepts no responsibility  for changes
>> made after they were sent or for other risks which arise as a result of
>> e-mail transmission, viruses, etc.
>>
>>
>> ---
>>
>> --
>> Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>> present their vision of the future. This family event has something for
>> everyone, including kids. Get more information and register today.
>> http://sdm.link/attshape
>> ___
>> Geoserver-devel mailing list
>> Geoserver-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>
> --
> Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel


--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] GeoServer Meeting 2016-06-28

[Jim Hughes]

Hi Torben,

Makes sense.  While it isn't a full-up integration test, I was able to 
build and run most of the GeoMesa unit tests with Guava 18. There was 
only one slightly issue; in one module, there was a method used which is 
not present in Guava 18.


I think if we removed that from GeoMesa, we'd be able to work with Guava 
11-18.  The GeoMesa datastore jars/zips/extensions targeting GeoServer 
2.8.x do not include Guava since Guava 17 is part of the GeoServer 
distribution.


Anyhow, having classloaders per extension might be necessary at some 
point, but I'd like to try and help avoid it;).


Cheers,

Jim


On 06/28/2016 07:51 PM, Torben Barsballe wrote:

Hi Jim

One thing we were looking at was trying to make sure that GeoMesa 
(using Guava 17 by way of Accumulo) and ElasticGeo (using Guava 18 by 
way of Elasticsearch) wouldn't cause conflicts if both extensions were 
installed. One suggestion was to try and have each extension run in 
its own class loader. However, if we want to have a different version 
of Guava for these two dependencies, then we could not have Guava in 
core GeoServer (else it would conflict with one of the extensions).


Torben

On Tue, Jun 28, 2016 at 3:43 PM, Jim Hughes <jn...@ccri.com 
<mailto:jn...@ccri.com>> wrote:


Hi Jody,

Thanks for the clarification; I didn't get it that the line was a
suggestion to remove Guava.

From a cursory look, it appears that GeoTools has few dependencies
on Guava.  For GeoServer, it seems that GWC and other pieces want
to be able to have a Guava cache.  I don't think there's a Java 8
analog for those caching options...

For my money, I'd be happy if GeoServer picked a version of Guava
(or a range of versions) to aim for.  Some of the Guava
functionality has stayed the same between versions, and modules
which can leverage that might work out better together.  (That is,
there'd be some utility in using more common Guava functionality
rather than a feature which is only in one version.)

Do you have more details about the dependency issues with
GeoMesa?  (I do see where the ElasticGeo instructions have you
ripping out Guava, etc.)

Joda doesn't use Guava.  Bringing up GeoServer and GeoMesa
dependencies made me think of the Joda updates.

Cheers,

Jim


On 06/28/2016 06:13 PM, Jody Garnett wrote:

As per meeting notes I would like to know if removing Guava is
something we can do over the course of 2.10 development.

So does Joda time use Guava as well?
--
Jody Garnett

On 28 June 2016 at 12:31, Jim Hughes <jn...@ccri.com
<mailto:jn...@ccri.com>> wrote:

Hi all,

Looks like there is plenty going on, I just wanted to add
some info re: GeoMesa and Guava.

Since GeoMesa code ends up being deployed in GeoServer,
Hadoop, and other environments, Guava is a provided
dependency.  We try to use Guava features which have remained
consistent between Guava versions (ranging from 11 to 17 or so).

From talking to Tyler on GeoMesa's Gitter, we figured out
that as GeoMesa moves to GT 15/GS 2.9, GeoMesa would need to
update the Joda time dependency to 2.8 or 2.9.

Let me know if there's a better practice or thing I can do to
help out, etc.

Cheers,

Jim

On 06/28/2016 12:34 PM, Jody Garnett wrote:


Version hell:
- Guava --> migrate to Java 8 (conflict with ElasticGeo and
GeoMesa). Consder removing as.




--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT
Park in San
Francisco, CA to explore cutting-edge tech and listen to tech
luminaries
present their vision of the future. This family event has
something for
everyone, including kids. Get more information and register
today.
http://sdm.link/attshape
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
<mailto:Geoserver-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/geoserver-devel






--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park
in San
Francisco, CA to explore cutting-edge tech and listen to tech
luminaries
present their vision of the future. This family event has
something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
<mailto:Geoserver-devel@lists.sourceforge.net>
https://lists.sourcef

Re: [Geoserver-devel] GeoServer Meeting 2016-06-28

[Jim Hughes]

Hi Jody,

Thanks for the clarification; I didn't get it that the line was a 
suggestion to remove Guava.


From a cursory look, it appears that GeoTools has few dependencies on 
Guava.  For GeoServer, it seems that GWC and other pieces want to be 
able to have a Guava cache.  I don't think there's a Java 8 analog for 
those caching options...


For my money, I'd be happy if GeoServer picked a version of Guava (or a 
range of versions) to aim for.  Some of the Guava functionality has 
stayed the same between versions, and modules which can leverage that 
might work out better together.  (That is, there'd be some utility in 
using more common Guava functionality rather than a feature which is 
only in one version.)


Do you have more details about the dependency issues with GeoMesa? (I do 
see where the ElasticGeo instructions have you ripping out Guava, etc.)


Joda doesn't use Guava.  Bringing up GeoServer and GeoMesa dependencies 
made me think of the Joda updates.


Cheers,

Jim

On 06/28/2016 06:13 PM, Jody Garnett wrote:
As per meeting notes I would like to know if removing Guava is 
something we can do over the course of 2.10 development.


So does Joda time use Guava as well?
--
Jody Garnett

On 28 June 2016 at 12:31, Jim Hughes <jn...@ccri.com 
<mailto:jn...@ccri.com>> wrote:


Hi all,

Looks like there is plenty going on, I just wanted to add some
info re: GeoMesa and Guava.

Since GeoMesa code ends up being deployed in GeoServer, Hadoop,
and other environments, Guava is a provided dependency.  We try to
use Guava features which have remained consistent between Guava
versions (ranging from 11 to 17 or so).

From talking to Tyler on GeoMesa's Gitter, we figured out that as
GeoMesa moves to GT 15/GS 2.9, GeoMesa would need to update the
Joda time dependency to 2.8 or 2.9.

Let me know if there's a better practice or thing I can do to help
out, etc.

Cheers,

Jim

On 06/28/2016 12:34 PM, Jody Garnett wrote:


Version hell:
- Guava --> migrate to Java 8 (conflict with ElasticGeo and
GeoMesa). Consder removing as.




--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park
in San
Francisco, CA to explore cutting-edge tech and listen to tech
luminaries
present their vision of the future. This family event has
something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
<mailto:Geoserver-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/geoserver-devel




--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] GeoServer Meeting 2016-06-28

[Jim Hughes]

Hi all,

Looks like there is plenty going on, I just wanted to add some info re: 
GeoMesa and Guava.


Since GeoMesa code ends up being deployed in GeoServer, Hadoop, and 
other environments, Guava is a provided dependency.  We try to use Guava 
features which have remained consistent between Guava versions (ranging 
from 11 to 17 or so).


From talking to Tyler on GeoMesa's Gitter, we figured out that as 
GeoMesa moves to GT 15/GS 2.9, GeoMesa would need to update the Joda 
time dependency to 2.8 or 2.9.


Let me know if there's a better practice or thing I can do to help out, etc.

Cheers,

Jim

On 06/28/2016 12:34 PM, Jody Garnett wrote:


Version hell:
- Guava --> migrate to Java 8 (conflict with ElasticGeo and GeoMesa). 
Consder removing as.


--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Using geoserver like spatial proxy

[Jim Hughes]

Hi Jorge,

I worked with the QGIS GeoServer plugin and the GeoServer LDAP plugin 
some last weekend, and I wanted to share some of my experience and make 
some suggestions.


I was able to setup use the LDAP jar from the GeoServer tutorial as a 
GeoServer role service.  Leveraging that, I was able to lock down 
workspaces and control read/write and admin abilities.


In order to use the QGIS GeoServer plugin to administer GeoServer with 
one of the ldap users, I did have to fiddle with the security settings a 
bit.  Changing the interceptor on the rest endpoints from 
'restInterceptor' to 'interceptor' seemed to make things go.  I haven't 
had a chance to dig into what that difference provides.


My recommendation would be that GeoServer admins use the GeoServer web 
UI, and that the GIS professionals who can update layers do so using 
QGIS.  Those users actually don't need to use the plugin.  If you 
register layers as WFS in QGIS, and then make changes, those updates 
will be pushed back to the WFS server via transactions.


Unprivileged users can access WFS via QGIS or a Leaflet/OpenLayers 
powered UI as normal.


Does that cover your use case?  Where would more detail help?

Cheers,

Jim

On 5/26/2016 6:27 AM, Jorge Infante wrote:

Hi, Jim.

I understand everything explained.
And I understand that, in principle, the safety management geoserver 
is focusing on what the administration (on the one hand, aspects of 
infrastructure, on the website, and on the other hand, the add and 
drop of layers, both on the website and in the api interface).
But in the life of the spatial layers, there is a loading time of new 
layers (many, at first, some, over time), but what remains is the 
maintenance of the layers that remains until the end of the life of 
the layer.
To give an example, I add the layer with streets of the city (a layer 
composed of alphanumeric data of the street, and segments of the 
block, where I store, for example, a graphics poly-line for each 
segment, and that, in itself, is the space) element.
Once I did load the layer, then what remains is opening new streets 
(street segments), changes in vehicular sense, annulments street, 
etc., all depending on changes in the urban layout.
In these cases, we have, cartographic's users making those changes 
(which should have access rules for additions, deletions and 
modifications of that layer) and the rest of the people, using the 
layer as a reference, to update other layers, example, traffic lights, 
trees, bus tours, etc.
Another example: Parcels layer in the city, from making restitution 
based on a satellite photo or a flight.
There is a initial load, to add all parcels, and then the rest will be 
divisions of parcels or associations thereof, for real-estate market 
transactions, operations of demolition and new construction, with the 
passage of time, or simply changes takes the neighbor on his parcel, 
lifting a second floor for the son who was to live, etc.
The first part (creating complete parcels layer), an administrator can 
do with existing tools.
Instead, all the others will make a specialized user, from qgis 
(desktop edition), bringing the layer, changing some records, and 
recording them (using the roles that allow you to modify the parcel 
layer). At another point, a user will seek information about cadastre 
(parcels and owners).

This user should only have read rights on that layer.
So that I can accomplish this having a direct connection to the base 
(which has innumerable issues of inefficiency in performance and / or 
safety). I need to use geoserver (as my only proxy spatial data) so 
that validates my ldap account through (only validation, like any 
other municipal application), and then use my rights enabling 
authorization writing about those layers only the administrator of 
spatial data, so ordered.
To do this, I need, or have a mechanism through which read my roles 
(ie, my right to modify the layers, not only create them) or, if not, 
see what the best solution.
And no use catch the admin password qgis in the environment, since 
that would put a weak point in the security chain, and security of an 
application is as strong as its weakest link.

I do not know if I managed to explain.

Thanks for your patient.

jorge infante

2016-05-24 12:10 GMT-03:00 Jim Hughes <jn...@ccri.com 
<mailto:jn...@ccri.com>>:


Hi Jorge,

We are quite happy to help.  Overall, GeoServer has lots with
security, and I learned most of what I know from reading the docs
here (1).

It sounds like you have two tiers of admins: 1) website+GeoServer
admins and 2) layer/workspace-only admins.  It has been a few
months, but I believe I was able to use this tutorial (2) to
connect GeoServer to an existing LDAP server.

Additionally, if I remember, I was able to map an LDAP group/role
to a GeoServer role.  Once that is setup, you could set up a
GeoServer role a workspace administrator 

Re: [Geoserver-devel] Using geoserver like spatial proxy

[Jim Hughes]

Hi Jorge,

We are quite happy to help.  Overall, GeoServer has lots with security, 
and I learned most of what I know from reading the docs here (1).


It sounds like you have two tiers of admins: 1) website+GeoServer admins 
and 2) layer/workspace-only admins.  It has been a few months, but I 
believe I was able to use this tutorial (2) to connect GeoServer to an 
existing LDAP server.


Additionally, if I remember, I was able to map an LDAP group/role to a 
GeoServer role.  Once that is setup, you could set up a GeoServer role a 
workspace administrator (see link #3).  A workspace admin can add and 
remove layers within a workspace, but they cannot perform general 
GeoServer administration.


I've done most of this configuration via the GeoServer web UI, so I 
don't readily know the answers to some of your questions about what 
files on disk look like.


Feel free to ask more questions.

Cheers,

Jim

1.  http://docs.geoserver.org/latest/en/user/security/index.html
2. 
http://docs.geoserver.org/latest/en/user/security/tutorials/ldap/index.html
3. 
http://docs.geoserver.org/latest/en/user/security/layer.html#providing-restricted-administrative-access


On 5/24/2016 5:58 AM, Jorge Infante wrote:

Ok, Jim.
The problem I see with (1) is that if I give the user permissions 
administration when connected via plug qgis then my problem would be 
in that same user could access the website, and do things "unwanted".
We try to restrict the roles for updating processes are performed only 
by persons authorized to do so in each layer. But, anyway, this gave 
me an idea.
If I had replicated ldap roles within geoserver (which would keep 
management within ldap accounts and access permissions to resources 
within geoserver), each user would be allowed only does what the role 
that authorizes it. But, of course, it is a mix of authorizations, and 
do not know whether it is intended.

What I see is that rest.properties, mentions "admin".
admin that could become a role?
I'm reviewing the matter.
Actually, for me, the solution is that if rest-api delegated 
authentication functionality in ldap, also made him the authorization.
I think, like, the rest.properties file must exist for match somehow, 
which is received from the socket with the internal structure of 
geoserver.
Well, I'm still reviewing the issue, at least, this allows me to meet 
product issues that otherwise would not have traveled.


Thanks a lot for your patient, again

jorge infante

2016-05-23 9:11 GMT-03:00 Jim Hughes <jn...@ccri.com 
<mailto:jn...@ccri.com>>:


Hi Jorge,

It sounds like you have two broad tasks:  1) managing layers
(while respecting user roles provided by LDAP), and 2) viewing and
updating data.

Building on what Andrea mentioned, if LDAP is your role management
process, you may need to configure certain LDAP users/groups to
have the GeoServer admin role.  At the moment, what happens when
you log into the GeoServer web UI with your ldap credentials?  (I
have experimented with this with PKI certs, so that may be a bad
question.)

Once security is handled, you might look at the existing QGIS
GeoServer plugin (1).  It'll may require some updates based on the
LDAP security concerns.

For the second I believe QGIS supports WFS-T for layers registered
through WFS.  Any layer registration from the GeoServer plugin
would likely use this approach, so you might just have to test out
making edits and saving them.

Cheers,

Jim

1.
http://blog.geoserver.org/2015/12/23/geoserver-explorer-plugin-for-qgis/
Source: https://github.com/boundlessgeo/qgis-geoserver-plugin
Docs: http://boundlessgeo.github.io/qgis-geoserver-plugin/index.html
https://plugins.qgis.org/plugins/geoserverexplorer/


On 5/23/2016 7:58 AM, Andrea Aime wrote:

Hi Jorge,
as far as I know (but I have vague memories) the REST API right
now demands admin rights to be accessed, and the
rest.properties file does little or nothing in that regard, e.g.
one cannot open the REST api to non admin users.
I believe this changed when per workspace services where
introduced... if this is confirmed we might want to just
drop the documentation for rest.properties.

I've cc'ed Justin, hopefully he's got a more precise idea of
what's going on here

Cheers
Andrea


On Mon, May 23, 2016 at 1:46 PM, Jorge Infante
<joluinfa...@gmail.com <mailto:joluinfa...@gmail.com>> wrote:

Hi.
I'm trying to work in a plugin for qgis, using geoserver as a
proxy to spatial layers.
I did check the rest api, but, this interface only works for
internal users (like admin/geoserver).
I need connect from the qgis using ldap authentication (like
the web application).
I did check if I use the code:

cat=Catalog("http://"+ip+":8080/geoserver/res

Re: [Geoserver-devel] Using geoserver like spatial proxy

[Jim Hughes]

Hi Jorge,

It sounds like you have two broad tasks:  1) managing layers (while 
respecting user roles provided by LDAP), and 2) viewing and updating data.


Building on what Andrea mentioned, if LDAP is your role management 
process, you may need to configure certain LDAP users/groups to have the 
GeoServer admin role.  At the moment, what happens when you log into the 
GeoServer web UI with your ldap credentials?  (I have experimented with 
this with PKI certs, so that may be a bad question.)


Once security is handled, you might look at the existing QGIS GeoServer 
plugin (1).  It'll may require some updates based on the LDAP security 
concerns.


For the second I believe QGIS supports WFS-T for layers registered 
through WFS.  Any layer registration from the GeoServer plugin would 
likely use this approach, so you might just have to test out making 
edits and saving them.


Cheers,

Jim

1. http://blog.geoserver.org/2015/12/23/geoserver-explorer-plugin-for-qgis/
Source: https://github.com/boundlessgeo/qgis-geoserver-plugin
Docs: http://boundlessgeo.github.io/qgis-geoserver-plugin/index.html
https://plugins.qgis.org/plugins/geoserverexplorer/

On 5/23/2016 7:58 AM, Andrea Aime wrote:

Hi Jorge,
as far as I know (but I have vague memories) the REST API right now 
demands admin rights to be accessed, and the
rest.properties file does little or nothing in that regard, e.g. one 
cannot open the REST api to non admin users.
I believe this changed when per workspace services where introduced... 
if this is confirmed we might want to just

drop the documentation for rest.properties.

I've cc'ed Justin, hopefully he's got a more precise idea of what's 
going on here


Cheers
Andrea


On Mon, May 23, 2016 at 1:46 PM, Jorge Infante > wrote:


Hi.
I'm trying to work in a plugin for qgis, using geoserver as a
proxy to spatial layers.
I did check the rest api, but, this interface only works for
internal users (like admin/geoserver).
I need connect from the qgis using ldap authentication (like the
web application).
I did check if I use the code:

cat=Catalog("http://"+ip+":8080/geoserver/rest/;, "jinfant0",
myldappass)

The geoserver code are validating with ldap my user & pass (I did
debug to code):

23 may 07:07:56 DEBUG [geoserver.security] - ==on

guavaAuthenticationCacheImpl.put(basic,jinfant0:570d0722c55d10f77243dfd1d8f00e77,org.springframework.security.authentication.UsernamePasswordA
uthenticationToken@4aff155f: Principal:
org.springframework.security.ldap.userdetails.LdapUserDetailsImpl@aff52e97:
Dn: uid=jinfant0,ou=cuentas,dc=rosario,dc=gov,dc=ar; Username:
jinfant0; Password: [
PROTECTED]; Enabled: true; AccountNonExpired: true;
CredentialsNonExpired: true; AccountNonLocked: true; Granted
Authorities: ROLE_ADMINISTRATOR, ROLE_CARTOGRAFIA_RO,
ROLE_GROUP_ADMIN; Credentials: [PROTECTED]; Authenticated: true;
Details:
org.geoserver.security.filter.GeoServerWebAuthenticationDetails@957e:
RemoteIpAddress: 127.0.0.1; SessionId: null; Granted Authorities:
ROLE_AUTHENTICATED, ROLE_ADMINISTRATOR, ROLE_CARTOGRAFIA_RO,
ROLE_GROUP_ADMIN,etc)==
23 may 07:07:56 DEBUG [geoserver.security] - AuthenticationCache
adding new entry for basic, jinfant0:570d0722c55d10f77243dfd1d8f00e77
23 may 07:07:56 DEBUG [geoserver.security] - Cache entries #: 0
23 may 07:07:56 DEBUG [geoserver.security] - AuthenticationCache
added new entry for basic, jinfant0:570d0722c55d10f77243dfd1d8f00e77
23 may 07:07:56 DEBUG [geoserver.security] - Cache entries #: 1

But, then, the rest code are using authorization information from
rest.properties (RESTAccessRuleDAO.java)
The web app code are using authorization information from
layers.properties (DataAccessRuleDAO). On this file, I have:

  muni.*.w=ROLE_CARTOGRAFIA_RW
  muni.manzanas.r=ROLE_CARTOGRAFIA_RO
  mode=HIDE

Then, we have two worlds to access same data.
I'd like, from a plugin on qgis:
* Get list of layers authorized to authenticaded user (using the
value for "mode=" in the layers.properties).
* Get layers for read using wfs or wms methods.
* Update elements of layers, using wfs-t methods.
* Another similar things.

I did try using the csw catalog, but, this, don't user the
authentication methods.

My boss don't enable to use my spatial database open to network.
Then, I need use geoserver to access to it.

Can you help me about where I can go with it?

PD: If necessary, I can help with the adequacy of the code.

TIA
jorge infante
rosario - santa fe - argentina




--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition
of MDM
  

Re: [Geoserver-devel] Feature freeze: do we need to amend our release process?

[Jim Hughes]

Hi all,

Sorry for the confusion I may have caused.  My attendance was to help 
track a particular GeoTools PR to handle unavailable factories.  The 
issue came up while testing GeoMesa with GeoTools 15-RC1.  Jody's PR 
here (1) was to help fix that.  Simone and Andrea had left some helpful 
feedback, and I wanted to know if I could do anything to help wrap up 
that work.  That PR is mentioned briefly in the meeting round-up.


On Tuesday, as we continued through the PRs, Jody asked about Andrew's 
JSON work (2).  He thought it had been ready to merge for a few weeks 
pending a fix to the compilation issues.  Since Jody seemed to be ok 
with merging the PR, I addressed the build error.


That discussion wasn't captured in the meeting notes, and there was no 
vote to include the PR.  Tuesday's meeting was a tough one for 
communication.


I see no problem in reverting the commit on the 2.9.x series.

Cheers,

Jim

1. https://github.com/geotools/geotools/pull/1192
(This blocker did get merged here: 
https://github.com/geotools/geotools/commit/3a8373cdd95689ec979a62606afcf6f533f32d8b?diff=unified. 
Thanks!)


2. https://github.com/geoserver/geoserver/pull/1524

On 5/21/2016 9:06 AM, Jody Garnett wrote:

I acted as the volunteer making the release.

I am happy to back out the change if the mailing list considers it 
appropriate. This release has many problems, including a long delay, 
and I do not want to get held up over an improvement to JSON formatting.


--
Jody Garnett

On 21 May 2016 at 06:02, Andrea Aime > wrote:


On Sat, May 21, 2016 at 2:56 PM, Jody Garnett
> wrote:

The first feature was discussed at the skype meeting, it has
been waiting on docs for quite some time and is important to
the downstream GeoMesa project. I figured if James was willing
to attend our meeting to coordinate and explain its importance
that I could help with the docs and see that it was included.


Did you have PSC majority during the meeting, was there a vote?
What project procedure did you call upon
to justify the backport during feature freeze?
Has the voice meeting become the place where "real decisions" are
made, regardless of the PSC?
That would also require an amendment to procedures I guess.

Ben was apparently at the meeting, and yet he looks surprised by
the backport, was it actually discussed to start with?

Cheers
Andrea

-- 
==

GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313 
fax: +39 0584 1660272 
mob: +39  339 8844549 

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica
e/o nel/i file/s allegato/i sono da considerarsi strettamente
riservate. Il loro utilizzo è consentito esclusivamente al
destinatario del messaggio, per le finalità indicate nel messaggio
stesso. Qualora riceviate questo messaggio senza esserne il
destinatario, Vi preghiamo cortesemente di darcene notizia via
e-mail e di procedere alla distruzione del messaggio stesso,
cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti,
copiarlo, od utilizzarlo per finalità diverse, costituisce
comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended
solely for the attention and use of the named addressee(s) and may
be confidential or proprietary in nature or covered by the
provisions of privacy act (Legislative Decree June, 30 2003,
no.196 - Italy's New Data Protection Code).Any use not in accord
with its purpose, any disclosure, reproduction, copying,
distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please
contact immediately the sender by telephone, fax or e-mail and
delete the information in this message that has been received in
error. The sender does not give any warranty or accept liability
as the content, accuracy or completeness of sent messages and
accepts no responsibility  for changes made after they were sent
or for other risks which arise as a result of e-mail transmission,
viruses, etc.


---

Re: [Geoserver-devel] Adding MBTiles Support in GWC

[Jim Hughes]

Hi Nuno,

If I understood correctly, Dave Blasby's presentation about vector tiles 
at FOSS4G NA two weeks ago made it sound like there was already 
something that GWC could do for some of the vector tile formats.

I take it that MBtiles are outside of that basic GWC integration?

Anyhow, I'm excited to see GeoServer/GWC have improved vector tile support!

Cheers,

Jim

On 05/19/2016 06:00 AM, Nuno Oliveira wrote:
> Hi all,
> sorry for the cross posting.
>
> We would like to add MBTiles support to GWC.
> Follows a description of the work with the main issues\limitations.
>
> I would like to have community feedback on this, by the way is there a better 
> way to propose this work ?
>
> * MBtiles and SQLitle *
>
> MBtiles is a specification that describe how to store tiles in an SQLite 
> database, this will allow us to store many tiles in a single SQLite
> file avoiding us file systems headaches:
> https://github.com/mapbox/mbtiles-spec/blob/master/1.1/spec.md.
>
> We can rely on GeoTools gt-mbtiles module for reading and writing MBTiles, 
> this way most of the work of implementing this blobstore will be
> managing SQLite connections and SQLite files.
>
> SQLite files cannot be managed as simple files. When connections to an SQLite 
> database are open we should not delete, move or switch the
> associated file. Databases files can be filled with "empty space" after 
> deleting an huge amount of data or can become fragmented after
> frequent inserts, updates or delete operations.
>
> SQLite documentation warns us against putting databases files on a shared 
> file system if multiple process need access to it (which is our
> case). Unless we can rely on a distributed lock mechanism SQLite databases 
> files should not be used with shared stores.
>
> * VACUUM and DiskQuota *
>
> To remove the fragmented space (or the empty space), the VACUUM command needs 
> to be executed. Although, performing a VACUUM command as a few
> drawbacks:
>
>  - During a VACUUM twice the size of the original database file is 
> required in disk.
>  - During the VACUUM operation no access to the database is allowed.
>  - The VACUUM operation copies the whole database which can take minutes.
>
> For these reasons the VACUUM command cannot  be performed after each 
> operation. When possible we will avoid creating fragmented space. For
> example, during a truncate operation we may prefer remove a whole SQLilte 
> file instead of deleting part of is content. Another consequence
> of the fragmented space is that DiskQuota will not be compatible with this 
> blobstore.
>
> * MBTiles Granularity *
>
> Reading and writing tiles on an SQLite database will be slower than writing 
> on a file system but will allow us to avoid file system
> headaches. In order to limit the amount of contention on each single MBTiles 
> file we will allow users to decide the granularity of the files
> so that instead of having a single file for each single layer we will allow 
> users to have more granularity.
>
> MBTiles force us to have at least a file per layer and format. If we want to 
> support more CRSs we will also need a file for each CRSs. By
> configuration it will be possible to configure the granularity  of the 
> database files. By default we will have a granularity per layer, crs,
> format and zoom level. As an instance something like this could be offered:
>
>  
> /path/to/{grid}/{dim}/{tileset}/{z}/{x}-{y}.sqlite
> 1000
> 1000
>  
>
> In this case we should include the {x}, {y} and {z} replacements in the 
> template determining the file to use. In the previous example, tile
> (z,x,y)=(15,3024,1534) would be stored in a file named 
> /path/to/g/mytileset/15/3000-1000.sqlite3 and tile (5,2,8) would be stored in 
> a file
> named /path/to/g/mytileset/5/0-0.sqlite3.
>
> With more databases files we have more performance but we will have also more 
> files to manage on the file system. In addition we can couple
> this with the in-memory cache in order to improve tile serving performance.
>
> * Connection Pooling and Performance *
>
> SQLite allow multiple readers but only allow one writer at the time which 
> will block the entire database. At most only one connection should
> be open to each SQLite database, the total number of open connections is 
> limited by the number of open files allowed by the OS (in linux
> this is controlled by the ulimit). A connection pool that will control the 
> number of open connections and that will be responsible to manage
> the connections will be implemented.
>
> * Replace Operation *
>
> As said before, if the cache is running we cannot simply switch SQLite files, 
> we need to make sure that all connections are closed. A
> replace operation will be created for this propose. The replace operation 
> will first copy the new file side by side the old one, then block
> the requests to the old file, tear down the store, delete the old one, rename 
> the new file to 

Re: [Geoserver-devel] GeoTools / GeoServer Meeting 2016-05-17

[Jim Hughes]

Indeed.  Where are we on getting Kevin's medal of valor minted?

On 05/18/2016 04:26 PM, Ben Caradoc-Davies wrote:
> Close: we had a pull request section and removed it when most were for
> the release, hence the misunderstanding.  :-)
>
> Sorry, the minutes should have been clearer. It was a hectic meeting,
> with Skype problems, switch to Hangouts, screen sharing reviews, and
> more. Very productive, but not an ordinary meeting.
>
> On 19/05/16 07:06, Andrea Aime wrote:
>> I guess you switched from release discussion to general pull request review
>> without
>> creating a new section in the minutes, hence the misunderstanding


--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] In-memory vs on-disk sorting

[Jim Hughes]

Hi all,

Will looking into some slow WFS paging/sorting results, I found that the 
hint MAX_MEMORY_SORT is both 1) really low (1000) and 2) not 
configurable from the commandline or GeoServer's UI.

Would anyone be fussed if we bumped the value from 1000? (Configured 
here: (1).)  Would something like 100k be ok given that RAM is cheap?

Second, would it make sense for this option to be configured on 
GeoServer's Settings->Global page?

For my current need, I can use some of my own classes which are 
instantiated a GeoServer startup to call 
'Hints.putSystemDefault(Hints.MAX_MEMORY_SORT, BIGGER_NUMBER)' manually

Thanks in advance for any feedback,

Jim

1. 
https://github.com/geotools/geotools/blob/master/modules/library/main/src/main/java/org/geotools/data/sort/MergeSortDumper.java#L93

--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] [Geotools-devel] Reading GeoTiffs from HDFS

[Jim Hughes]

Hi Chris,

Nice!  That's a fun find.

Generally, I do like the idea of using Map/Reduce or Spark to 
pre-generate tiles or an image pyramid.  We've kicked around the idea of 
GWC + M/R a few times in passing.  If one has Hadoop infrastructure 
hanging around, it might make sense to use GeoTrellis, SpatialHadoop 
(GeoJini), etc. for some of that processing.

Either way, being able to read the odd raster file straight from hdfs:// 
or s3:// and have it cached in memory seems like an amusing/useful 
project.  I'm hopeful we can nail down the details.

Cheers,

Jim

On 04/22/2016 02:27 PM, Chris Snider wrote:
> I did find this reference (helpful ?):
> https://github.com/openreserach/bin2seq/blob/master/src/main/java/com/openresearchinc/hadoop/sequencefile/GeoTiff.java
>
> " /@formatter:off
> /**
>   *
>   * A program to demo retrive attributes from Geotiff images as Hadoop 
> SequenceFile stored on hdfs:// or s3://
>   *
>   *
>   * @author heq
>   */
> // @formatter:on"
>
> Chris Snider
> Senior Software Engineer
> Intelligent Software Solutions, Inc.
>
>
>
> -Original Message-
> From: Chris Snider [mailto:chris.sni...@issinc.com]
> Sent: Friday, April 22, 2016 12:11 PM
> To: Jim Hughes <jn...@ccri.com>; Simone Giannecchini 
> <simone.giannecch...@geo-solutions.it>
> Cc: geoserver-devel@lists.sourceforge.net; GeoTools Developers list 
> <geotools-de...@lists.sourceforge.net>
> Subject: Re: [Geoserver-devel] [Geotools-devel] Reading GeoTiffs from HDFS
>
> Hi,
>
> I don't know that much about HDFS, but is there something that can be setup 
> like a map/reduce function directly in the HDFS servers that can do some of 
> the restriction of byte level data returned? Yarn/Sparql, some other acronym? 
>  I assume it would have to be administrator responsibility to add said 
> process to the server stack if it is even possible.
>
> Chris Snider
> Senior Software Engineer
> Intelligent Software Solutions, Inc.
>
>
> -Original Message-
> From: Jim Hughes [mailto:jn...@ccri.com]
> Sent: Friday, April 22, 2016 12:05 PM
> To: Simone Giannecchini <simone.giannecch...@geo-solutions.it>
> Cc: geoserver-devel@lists.sourceforge.net; GeoTools Developers list 
> <geotools-de...@lists.sourceforge.net>
> Subject: Re: [Geoserver-devel] [Geotools-devel] Reading GeoTiffs from HDFS
>
> Hi Simone,
>
> Thanks for the feedback!
>
> As quick response, for #1, I agree that using mosaicing / an image
> pyramid would be a great option.  I was mainly working at the prototype
> phase, and I wanted to have a discussion on the mailing lists
> (especially since changes are required in ImageIO-Ext or GeoTools and
> GeoServer.)
>
> For #2, I do like the idea of having a cahce in the ImageInputStream.
>   From that suggestion, I take it that you'd be willing to entertain
> changes to the current ImageInputStreams and the additional of some way
> to cache data.
>
> In terms of caching, do you have any suggestions?  Also, I'd be
> interested in any advice for how we can configure that cache and make
> those options available to a GeoServer admin appropriately.
>
> Further, at a high-level, should the goal for this work be a community
> module?
>
> Cheers,
>
> Jim
>
> On 04/22/2016 01:49 PM, Simone Giannecchini wrote:
>> Dear Jim,
>> quick feedback.
>>
>> First of all congratulation on making this work. As I suspected the
>> bottleneck is getting the data out of HDFS.
>> I can think about two things (which we are not mutually exclusive):
>>
>> -1- Maybe complex, put smaller bits into HFDS and use the mosaic to
>> serve or even develop a light(er)weight layer that can pull the
>> granules.
>>
>> This would help with WMS requests over large files as you'll end up
>> use smaller chunks to satisfy them most of the time
>>
>> -2- We could build a more complex ImageInputStream that:
>>
>> - has an internal cache (file and or memory) that does not get thrown
>> away upon each request but tends to live longer for each single file
>> in HDF
>> - we would have different streams reuse the same cache. Multiple
>> requests might read data from the cache concurrently but when data is
>> not there, we would block the thread for the request, go back to HFDS,
>> pull the data, write to the cache and so on
>>
>> We could put together 1 and 2 to make things faster.
>>
>> Hope this helps, anyway, I am in favour of exploring this in order to
>> allow the GeoServer stack to support data from HDFS.
>>
>> Regards,
>> Simone Giannecchini
>> ==
>> GeoServer Professional Services from the experts

Re: [Geoserver-devel] [Geotools-devel] Reading GeoTiffs from HDFS

[Jim Hughes]

Hi Simone,

Thanks for the feedback!

As quick response, for #1, I agree that using mosaicing / an image 
pyramid would be a great option.  I was mainly working at the prototype 
phase, and I wanted to have a discussion on the mailing lists 
(especially since changes are required in ImageIO-Ext or GeoTools and 
GeoServer.)

For #2, I do like the idea of having a cahce in the ImageInputStream.  
 From that suggestion, I take it that you'd be willing to entertain 
changes to the current ImageInputStreams and the additional of some way 
to cache data.

In terms of caching, do you have any suggestions?  Also, I'd be 
interested in any advice for how we can configure that cache and make 
those options available to a GeoServer admin appropriately.

Further, at a high-level, should the goal for this work be a community 
module?

Cheers,

Jim

On 04/22/2016 01:49 PM, Simone Giannecchini wrote:
> Dear Jim,
> quick feedback.
>
> First of all congratulation on making this work. As I suspected the
> bottleneck is getting the data out of HDFS.
> I can think about two things (which we are not mutually exclusive):
>
> -1- Maybe complex, put smaller bits into HFDS and use the mosaic to
> serve or even develop a light(er)weight layer that can pull the
> granules.
>
> This would help with WMS requests over large files as you'll end up
> use smaller chunks to satisfy them most of the time
>
> -2- We could build a more complex ImageInputStream that:
>
> - has an internal cache (file and or memory) that does not get thrown
> away upon each request but tends to live longer for each single file
> in HDF
> - we would have different streams reuse the same cache. Multiple
> requests might read data from the cache concurrently but when data is
> not there, we would block the thread for the request, go back to HFDS,
> pull the data, write to the cache and so on
>
> We could put together 1 and 2 to make things faster.
>
> Hope this helps, anyway, I am in favour of exploring this in order to
> allow the GeoServer stack to support data from HDFS.
>
> Regards,
> Simone Giannecchini
> ==
> GeoServer Professional Services from the experts!
> Visit http://goo.gl/it488V for more information.
> ==
> Ing. Simone Giannecchini
> @simogeo
> Founder/Director
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob:   +39  333 8128928
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> ---
> AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate.
> Il loro utilizzo è consentito esclusivamente al destinatario del
> messaggio, per le finalità indicate nel messaggio stesso. Qualora
> riceviate questo messaggio senza esserne il destinatario, Vi preghiamo
> cortesemente di darcene notizia via e-mail e di procedere alla
> distruzione del messaggio stesso, cancellandolo dal Vostro sistema.
> Conservare il messaggio stesso, divulgarlo anche in parte,
> distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità
> diverse, costituisce comportamento contrario ai principi dettati dal
> D.Lgs. 196/2003.
>
> The information in this message and/or attachments, is intended solely
> for the attention and use of the named addressee(s) and may be
> confidential or proprietary in nature or covered by the provisions of
> privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New
> Data Protection Code).Any use not in accord with its purpose, any
> disclosure, reproduction, copying, distribution, or either
> dissemination, either whole or partial, is strictly forbidden except
> previous formal approval of the named addressee(s). If you are not the
> intended recipient, please contact immediately the sender by
> telephone, fax or e-mail and delete the information in this message
> that has been received in error. The sender does not give any warranty
> or accept liability as the content, accuracy or completeness of sent
> messages and accepts no responsibility  for changes made after they
> were sent or for other risks which arise as a result of e-mail
> transmission, viruses, etc.
>
>
> On Sun, Apr 17, 2016 at 9:49 PM, Jim Hughes <jn...@ccri.com> wrote:
>> Hi all,
>>
>> I want to report on my success with registering and displaying GeoTiffs
>> stored on HDFS.  There are some limitations with this approach;
>> particularly, I am unsure if there's anyway to cache / memory-map the
>> data.  As such, I believe each request is re-downloading the entire file.
>>
>> Generally, I hope

Re: [Geoserver-devel] GeoTools / GeoServer Meeting 2016-04-19

[Jim Hughes]

Hi GeoServer-ers,

A PR for the Collections update is here: 
https://github.com/geoserver/geoserver/pull/1578.

Cheers,

Jim

On 04/19/2016 04:20 PM, Ben Caradoc-Davies wrote:
> GeoTools / GeoServer Meeting 2016-04-19
> ===
>
> Attending
> -
>
> Ben Caradoc-Davies
> Kevin Smith
> Jim Hughes
> Torben Barsballe
> Jody Garnett
> Dave Blasby
> Jukka Rahkonen
>
> Apologies
> -
>
> Brad Hards
> Andrea Aime
>
> Agenda
> --
>
> - Release of 15-beta2 / 2.9-beta2
> - Windows service wrapper licence
> - Apache Commons Upgrade?
> - Can we put AbstractDataStore in jail?
> - GeoMesa discussion
>
> Actions
> ---
>
> Actions from last meeting
> -
>
> - Ben: send an email to Emanuele to see if we can lock down GeoFence
> dependency for release [DONE]
> - Jody:  email GeoServer developer mailing list calling for nominations
> for OSGeo project officer
>
> Release of 15-beta2 / 2.9-beta2
> ---
>
> - Release process and pre-flight testing under way. We will need it to
> at least run prior to announcing.
>
> Todo:
> - login issue GEOS-7482 - who can work on this?
> - (jody) mac DMG not starting
> - (jody) bin download not starting on mac
> - (kevin) linux bin startup (openjdk and oracle) - worked fine except
> for GEOS-7482
> - windows not starting, Brad provided a workaround?
>
> Reason to do the beta is to confirm packaging is working, so we need to
> fix the above.
>
> Should we double back and include Justin's fix? Does it prevent PostGIS
> from functioning ... Ben says we should not release with failing build.
>
> Actions:
> - take startup issues to email
> - redo the geotools release
>
> Windows service wrapper licence
> ---
>
> [GEOS-7488] Windows service wrapper appears to have problematic license
> https://osgeo-org.atlassian.net/browse/GEOS-7488
>
> Compare:
> - https://github.com/geoserver/geoserver/tree/master/src/release/wrapper
> -
> https://github.com/geoserver/geoserver/tree/master/src/release/installer/win
> (MIT-License)
>
> The two wrapper.exe files are two different programs (different size).
>
> Action:
> - there are two versions in the codebase, do they both work?
> - We need more information, take to email list
>
> Apache Commons Upgrade?
> ---
>
> Can we update apache-commons-collections 3.1.0 --> 3.2.2 ?
>
> Yes - GeoTools 14.4 release is scheduled for next month.
>
> Can we put AbstractDataStore in jail?
> -
>
> Idea to put these into seperate gt-abstract-datastore module?
>
> Good communication/perhaps too late.
>
> GeoMesa discussion
> --
>
> GeoMesa is now updated to ContentDataStore - congrats!
>
> Discussion about hdfs URLs for distributed file system, anyone review
> tweaks to geotools/geoserver?
>
> (Tell wicket that other URL schemes are valid, and update geoserver file
> model, tell geotools SPI handlers for objects->inputstreams).
>
>


--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] Reading GeoTiffs from HDFS

[Jim Hughes]

Hi all,

I want to report on my success with registering and displaying GeoTiffs 
stored on HDFS.  There are some limitations with this approach; 
particularly, I am unsure if there's anyway to cache / memory-map the 
data.  As such, I believe each request is re-downloading the entire file.

Generally, I hope to document my approach well enough so that others 
could follow it (if needed) and to solicit feedback.  In terms of 
feedback, I'd love to hear 1) if there are improvements, and 2) if the 
changes are reasonable enough to be considered for a proposal/merge request.

That out of the way, here's the rough outline:

1.  Register additional URL handlers.
2.  Convince validation layers in GeoServer that 'hdfs' is an ok URL scheme.
3.  Get bytes out of the HDFS file.

For step 1, note that Java's URL scheme is pluggable via 
java.net.URLStreamHandler.  The docs(1) point out that one can call 
URL.setURLStreamHandlerFactory to setup a Factory to provide such a 
handler.  This method can only be called once, and folks from the 
internet (2) do yoga since Tomcat already registers a factory.  They 
seem to have missed the fact that the Tomcat factory actually lets you 
add your own.  I provide a gist (3) to show a little bean which will 
instantiate a Hadoop URL handler and try to install it using both of 
those methods.

There are two places I found in GeoServer which validate the URL given 
in the page for adding a GeoTiff.  The first is the GeoServer 
FileExistValidator which calls out to a Wicket UrlValidator. Telling the 
Wicket class to allow_all_schemes knocks out that issue.  For the 
second, in the FileModel, one needs to provide a happy path for URLs 
which are not local to the filesystem.  Those two small changes are here 
(4).

Once GeoServer will register a GeoTiff coverage with a non-'file://' 
URL, we need to read the bytes.  Javax has an interface 
javax.imageio.spi.ImageInputStreamSpi which adapts between instances of 
a particular class and an ImageInputStream.

For my prototype, I wrote an instance of this interface which takes a 
string, checks if it starts with "hdfs", creates a URL, and returns new 
MemoryCacheImageInputStream(url.openStream()).  The only problem with 
this approach is that there is already an implementation which handles 
Strings, and GeoTools's ImageIOExt tries the first one and skips any 
others.  One can update that handling (5) slightly to try all the 
handlers.  It'd probably be better to update (6) to try url.openStream 
as a fallback.

During testing, I worked with the sfdem.tif which ships with GeoServer.  
The hdfs layer was a little slower than the local filesystem layer, but 
it wasn't unusable.  To crank things up, I tried out a 600+ megabyte 
GeoTiff from Natural Earth, and it was downright slow.  Using a network 
monitor, I was able to observe network traffic consistent with the 
entire file being re-read for most requests.  I think this approach may 
be slightly useful for layers which are infrequently accessed and then 
only be a few users.

Thanks to everyone who had suggestions and encouragement for the 
original thread!

Cheers,

Jim

Step 1: Register additional URL handlers:

1. 
http://download.java.net/jdk7/archive/b123/docs/api/java/net/URL.html#URL%28java.lang.String,%20java.lang.String,%20int,%20java.lang.String%29

2. http://skife.org/java/url/library/2012/05/14/java_url_handlers.html

3. Gist for a bean to register the Hadoop URL handlers:
https://gist.github.com/jnh5y/1739baa42466d66e383fa26ffd7235ca

Step 2: GeoServer changes:
4. 
https://github.com/jnh5y/geoserver/commit/5320f26a0574f034433aa96097054ec1ec782d45
The FileModel change could be a little more robust.

Step 3: GeoTools changes:
5. 
https://github.com/jnh5y/geotools/commit/f2db29339c7f7e43d0c52ab93195babc1abb6f49

Or one could modify the URL handling here:
6. 
https://github.com/geosolutions-it/imageio-ext/blob/master/library/streams/src/main/java/it/geosolutions/imageio/stream/input/spi/URLImageInputStreamSpi.java#L88-L97




--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] [Geotools-devel] WFS Transaction XML parsing

[Jim Hughes]

Hi Andrea,

Sure.  To clarify, my goal is to add data to WFS transaction which will 
influence how it is written to Accumulo (and consequently queried back 
out).  In some sense, it'd be akin to providing ingest hints / 
instructions.  For example, suppose that some data could only be seen by 
'admin' users.  In a transaction, it'd be great to indicate which 
features are 'admin' only.


Just to say it out loud, the GeoServer authentication/authorization 
framework is awesome.  Anytime something hasn't been handled already, it 
seems that there is usually a pluggable extension point to address the 
situation.  For this task, the TransactionPlugins and Native tags do 
provide one general solution already.


Thanks,

Jim

On 04/08/2016 11:50 AM, Andrea Aime wrote:
On Fri, Apr 8, 2016 at 4:09 PM, Jim Hughes <jn...@ccri.com 
<mailto:jn...@ccri.com>> wrote:


My high-level goal is to find a way to add security info to a WFS
transaction. 



Can you elaborate why just an authentication + authorization rules
would not work?

Cheers
Andrea


--
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o 
nel/i file/s allegato/i sono da considerarsi strettamente riservate. 
Il loro utilizzo è consentito esclusivamente al destinatario del 
messaggio, per le finalità indicate nel messaggio stesso. Qualora 
riceviate questo messaggio senza esserne il destinatario, Vi preghiamo 
cortesemente di darcene notizia via e-mail e di procedere alla 
distruzione del messaggio stesso, cancellandolo dal Vostro sistema. 
Conservare il messaggio stesso, divulgarlo anche in parte, 
distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità 
diverse, costituisce comportamento contrario ai principi dettati dal 
D.Lgs. 196/2003.


The information in this message and/or attachments, is intended solely 
for the attention and use of the named addressee(s) and may be 
confidential or proprietary in nature or covered by the provisions of 
privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New 
Data Protection Code).Any use not in accord with its purpose, any 
disclosure, reproduction, copying, distribution, or either 
dissemination, either whole or partial, is strictly forbidden except 
previous formal approval of the named addressee(s). If you are not the 
intended recipient, please contact immediately the sender by 
telephone, fax or e-mail and delete the information in this message 
that has been received in error. The sender does not give any warranty 
or accept liability as the content, accuracy or completeness of sent 
messages and accepts no responsibility  for changes made after they 
were sent or for other risks which arise as a result of e-mail 
transmission, viruses, etc.



---


--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial! http://pubads.g.doubleclick.net/
gampad/clk?id=1444514301=/ca-pub-7940484522588532___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] [Geotools-devel] WFS Transaction XML parsing

[Jim Hughes]

Hi Justin,

Thanks.  I forgot to mention that I had seen the TransactionPlugin 
extension point; that one is awesome and I see how to use it support my 
second suggestion.


Would changes in the GML2/3ParsingUtils to inject attributes into a 
SimpleFeature's userData be sensible / more broadly useful?  I'm a bit 
shy about pushing hard for such a change since I am not sure about any 
other ramifications.


Thanks,

Jim

On 04/08/2016 10:45 AM, Justin Deoliveira wrote:


Hey Jim,

The wfs native element might be the cleanest way to handle this. I’ve 
seen folks use it before for security and validation type stuff with 
some success. In GeoServer you can plug in WFS transactions callbacks 
pretty easily using the TransactionPlugin 
<[https://github.com/geoserver/geoserver/blob/master/src/wfs/src/main/java/org/geoserver/wfs/TransactionPlugin.java]%28https://github.com/geoserver/geoserver/blob/master/src/wfs/src/main/java/org/geoserver/wfs/TransactionPlugin.java> 
extension point. It has direct access to the transaction object which 
has the native content on it.


If you do want to go with approach (1): during GML parsing I don’t 
believe there is any way to tag a GML attribute as something you want 
to store in user data. Folks might correct me on that one though. To 
support it I wonder if we could do something simple like a custom 
attribute on the gml attribute element. Something like:


|foo |

One potential downside might be validation… however in GeoServer last 
I checked we don’t validate features on the way in… mostly because 
it’s a pain to have to specify all the schema references properly so a 
parser can actually validate. It may also be there in the gml schema 
there is some attribute we might be able to use /abuse for this 
purpose… I can’t think of one off hand though.


As far as I know the feature parsing logic still lives in the 
GML3ParsingUtils and GML2ParsingUtils classes. To add some support for 
putting an attribute in user data rather than a normal attribute I 
think you would be looking at modifying this method 
<[https://github.com/geotools/geotools/blob/master/modules/extension/xsd/xsd-gml2/src/main/java/org/geotools/gml2/bindings/GML2ParsingUtils.java#L338-L362]%28https://github.com/geotools/geotools/blob/master/modules/extension/xsd/xsd-gml2/src/main/java/org/geotools/gml2/bindings/GML2ParsingUtils.java#L338-L362>.


As you’ll notice this only applies to simple features. If working with 
complex features i am actually not sure where that logic lives 
anymore. One of the app-schema folks can point you at that if need be.


Hope that helps!

-Justin



On Fri, Apr 8, 2016 at 8:09 AM Jim Hughes <jn...@ccri.com 
<mailto:jn...@ccri.com>> wrote:


Hi all,

Apologies for the cross-post, but my question hits a little of how
GeoServer handles WFS transactions and a little bit of how
GeoTools may
handle WFS/GML parsing.

My high-level goal is to find a way to add security info to a WFS
transaction.  I can see three big options:  1. add some bits to
the GML
feature / WFS call which would set a SimpleFeature's userData or
otherwise provide additional data, 2. leverage a WFS 'Native' tag,
or 3.
store the security info in the SimpleFeature.

I've got a pretty good handle on the last two options.  The first
option
would provide the greatest flexibility, so I'm wondering if anyone can
help point me in the right direction there.  (Or otherwise say
that this
is impossible without re-writing GT/GS XML handling...)

Thanks in advance,

Jim


--
___
GeoTools-Devel mailing list
geotools-de...@lists.sourceforge.net
<mailto:geotools-de...@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/geotools-devel



--
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] WFS Transaction XML parsing

[Jim Hughes]

Hi all,

Apologies for the cross-post, but my question hits a little of how 
GeoServer handles WFS transactions and a little bit of how GeoTools may 
handle WFS/GML parsing.

My high-level goal is to find a way to add security info to a WFS 
transaction.  I can see three big options:  1. add some bits to the GML 
feature / WFS call which would set a SimpleFeature's userData or 
otherwise provide additional data, 2. leverage a WFS 'Native' tag, or 3. 
store the security info in the SimpleFeature.

I've got a pretty good handle on the last two options.  The first option 
would provide the greatest flexibility, so I'm wondering if anyone can 
help point me in the right direction there.  (Or otherwise say that this 
is impossible without re-writing GT/GS XML handling...)

Thanks in advance,

Jim

--
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Custom URL protocol handling

[Jim Hughes]

Hi Andrea, Chris,

Andrea, thanks for the input.

Chris, it seems like several handlers could be gathered up for the 
one-go at registering them.  That said, I'm a little worried that if 
other applications in a container are trying to do the same, then we'll 
lose.  I don't know if that concern is a show-stopper or not.


Thanks,

Jim

On 04/04/2016 12:44 PM, Chris Snider wrote:


Hi,

I read the base question and the accepted answer from Andrea’s 
reference.  It seems the para 4 could be an issue requiring a wrapper 
to be written to handle multiple custom protocols.


Ref: 
http://stackoverflow.com/questions/26363573/registering-and-using-a-custom-java-net-url-protocol


“4 Finally register it during application's startup via 
URL#setURLStreamHandlerFactory() 
<http://docs.oracle.com/javase/8/docs/api/java/net/URL.html#setURLStreamHandlerFactory-java.net.URLStreamHandlerFactory-> 



URL.setURLStreamHandlerFactory(new CustomURLStreamHandlerFactory());

Note that the Javadoc 
<http://docs.oracle.com/javase/8/docs/api/java/net/URL.html#setURLStreamHandlerFactory-java.net.URLStreamHandlerFactory-> 
explicitly says that you can set it at most once. So if you intend to 
support multiple custom protocols in the same application, you'd need 
to generify the custom URLStreamHandlerFactory implementation to cover 
them all inside the createURLStreamHandler() method.”


So if an installation wants HDFS and not S3, or vice-versa, the 
wrapper class would have to know about and handle the referencing 
implementation for specific protocols encountered.  Thus we could also 
add “myprotocol”/”myspecialclass” and what-not to a Spring bean, I 
suppose, that could return the appropriate URLStreamHandler 
implemented in the “myspecialclass” or an exception as necessary.


Chris Snider

Senior Software Engineer

*Intelligent Software Solutions, Inc.*

Description: Description: Description: cid:image001.png@01CA1F1F.CBC93990

*From:*Andrea Aime [mailto:andrea.a...@geo-solutions.it]
*Sent:* Monday, April 04, 2016 9:23 AM
*To:* Jim Hughes <jn...@ccri.com>
*Cc:* Geoserver-devel <geoserver-devel@lists.sourceforge.net>
*Subject:* Re: [Geoserver-devel] Custom URL protocol handling

Hi Jim,

as said in the other mail, I don't know, but I'm afraid if you don't 
go for URL handlers


you'll have to modify more than just geotools and geoserver (and go 
down in imageio).


I was actually skeptical about joining this thread because I don't 
have any direct experience on this


subject, nor the time to perform research.

That said, if you look at my previous stackoverflow link it seems that 
URL handlers


can be registered programmatically

Cheers

Andrea

On Mon, Apr 4, 2016 at 4:53 PM, Jim Hughes <jn...@ccri.com 
<mailto:jn...@ccri.com>> wrote:


Hi Andrea, all,

In terms of ease, would it be preferable to 1) ask HDFS/S3 minded
users to add URL handlers to their JVM or 2) handle this at the
GeoTools/GeoServer level?

For #1, I get the sense that adding URL handlers is more
challenging.  Also, I doubt all installations would be ok with
steps which add things to the JVM setup.  On the plus side, it
might require little or no code changes on the GT/GS side of things.

For #2, I imagine there may be more code to update, etc.  As
Andrew points out, whenever a Java File is used directly, we might
have to tweak code.

Thoughts?

Tentatively, I'm for the second approach.

Jim

On 04/04/2016 10:42 AM, Andrea Aime wrote:

Hi Rich,

it should be something along these lines (as said, never tried
personally, was just barely aware it should be possible):


http://stackoverflow.com/questions/26363573/registering-and-using-a-custom-java-net-url-protocol

Cheers

Andrea

On Mon, Apr 4, 2016 at 4:37 PM, Rich Fecher <rfec...@gmail.com
<mailto:rfec...@gmail.com>> wrote:

It is definitely possible we missed an extension point to
register protocol handlers at the JVM level.  I just
hadn't thought of it at the time and didn't dig in, but
I'll keep it in mind.  Also, I'm curious if that works in
the case of 'hdfs' and 's3' protocol because then I'd
think it should work for us too.  Thanks!

On Mon, Apr 4, 2016 at 10:34 AM, Andrew Hulbert
<ahulb...@ccri.com <mailto:ahulb...@ccri.com>> wrote:

Yeah the only thing we will have to worry about is if
the code is written against java.io.File instead of
some other URL lib. At some point I guess we could dig
in and look. I'll ask Jim for more info and see if we
can mock it up...while we're at it we can do S3 or
something too for another test.

On Mon, Apr 04, 2016 at 04:31:13PM +0200, Andrea Aime
wrote:
 

Re: [Geoserver-devel] Custom URL protocol handling

[Jim Hughes]

To make this concrete, I think that any HDFS or S3 support would likely 
be a community module for a bit.  Proposing for #2 would involve any API 
work required, and then we could update existing plugins as needed.

Cheers,

Jim

On 04/04/2016 11:03 AM, Andrew Hulbert wrote:
> I thinks HDFS and S3 are stable enough to have some sort of support that 
> ships out of the box. The only worry I would have is the dependency chain 
> that comes with HDFS. If it proves to be larger than we'd like we can just 
> have good doc on installation...
>
> I support #2 as much as possible too. Having all of the code work against 
> InputStreams or URIs or other higher level abstractions is always more 
> flexible and also allows for new datastores and memory-based systems, etc.
>
> Overall, I think having native S3 and HDFS support positions GeoServer well 
> in the "big data" world too. Another option is to have a profile that builds 
> the war file with all the crazy cloud deps installed or something like that? 
> I'd just like to have a "works out of the box" turn-key type solution for 
> HDFS/S3/etc. in the future.
>
> Andrew
>
> On Mon, Apr 04, 2016 at 10:53:30AM -0400, Jim Hughes wrote:
>> Hi Andrea, all,
>>
>> In terms of ease, would it be preferable to 1) ask HDFS/S3 minded
>> users to add URL handlers to their JVM or 2) handle this at the
>> GeoTools/GeoServer level?
>>
>> For #1, I get the sense that adding URL handlers is more
>> challenging.  Also, I doubt all installations would be ok with steps
>> which add things to the JVM setup.  On the plus side, it might
>> require little or no code changes on the GT/GS side of things.
>>
>> For #2, I imagine there may be more code to update, etc.  As Andrew
>> points out, whenever a Java File is used directly, we might have to
>> tweak code.
>>
>> Thoughts?
>>
>> Tentatively, I'm for the second approach.
>>
>> Jim
>>
>> On 04/04/2016 10:42 AM, Andrea Aime wrote:
>>> Hi Rich,
>>> it should be something along these lines (as said, never tried
>>> personally, was just barely aware it should be possible):
>>>
>>> http://stackoverflow.com/questions/26363573/registering-and-using-a-custom-java-net-url-protocol
>>>
>>> Cheers
>>> Andrea
>>>
>>>
>>> On Mon, Apr 4, 2016 at 4:37 PM, Rich Fecher <rfec...@gmail.com
>>> <mailto:rfec...@gmail.com>> wrote:
>>>
>>> It is definitely possible we missed an extension point to register
>>> protocol handlers at the JVM level.  I just hadn't thought of it
>>> at the time and didn't dig in, but I'll keep it in mind.  Also,
>>> I'm curious if that works in the case of 'hdfs' and 's3' protocol
>>> because then I'd think it should work for us too.  Thanks!
>>>
>>> On Mon, Apr 4, 2016 at 10:34 AM, Andrew Hulbert <ahulb...@ccri.com
>>> <mailto:ahulb...@ccri.com>> wrote:
>>>
>>> Yeah the only thing we will have to worry about is if the code
>>> is written against java.io.File instead of some other URL lib.
>>> At some point I guess we could dig in and look. I'll ask Jim
>>> for more info and see if we can mock it up...while we're at it
>>> we can do S3 or something too for another test.
>>>
>>> On Mon, Apr 04, 2016 at 04:31:13PM +0200, Andrea Aime wrote:
>>> > On Mon, Apr 4, 2016 at 4:30 PM, Andrea Aime
>>> <andrea.a...@geo-solutions.it
>>> <mailto:andrea.a...@geo-solutions.it>>
>>> > wrote:
>>> >
>>> > > That said, I'm not sure this has ever been tried, not at
>>> any level, but
>>> > > especially with imageio-ext,
>>> > >
>>> >
>>> > Sorry, mis-typed, I meant jai-imageio there
>>> >
>>> > Cheers
>>> > Andrea
>>> >
>>> > --
>>> > ==
>>> > GeoServer Professional Services from the experts! Visit
>>> > http://goo.gl/it488V for more information.
>>> > ==
>>> >
>>> > Ing. Andrea Aime
>>> > @geowolf
>>> > Technical Lead
>>> >
>>> > GeoSolutions S.A.S.
>>> > Via di Montramito 3/A
>>> > 55054  Massarosa (LU)
>>> > phon

Re: [Geoserver-devel] Custom URL protocol handling

[Jim Hughes]

Hi Andrea, all,

In terms of ease, would it be preferable to 1) ask HDFS/S3 minded users 
to add URL handlers to their JVM or 2) handle this at the 
GeoTools/GeoServer level?


For #1, I get the sense that adding URL handlers is more challenging.  
Also, I doubt all installations would be ok with steps which add things 
to the JVM setup.  On the plus side, it might require little or no code 
changes on the GT/GS side of things.


For #2, I imagine there may be more code to update, etc.  As Andrew 
points out, whenever a Java File is used directly, we might have to 
tweak code.


Thoughts?

Tentatively, I'm for the second approach.

Jim

On 04/04/2016 10:42 AM, Andrea Aime wrote:

Hi Rich,
it should be something along these lines (as said, never tried 
personally, was just barely aware it should be possible):


http://stackoverflow.com/questions/26363573/registering-and-using-a-custom-java-net-url-protocol

Cheers
Andrea


On Mon, Apr 4, 2016 at 4:37 PM, Rich Fecher > wrote:


It is definitely possible we missed an extension point to register
protocol handlers at the JVM level.  I just hadn't thought of it
at the time and didn't dig in, but I'll keep it in mind.  Also,
I'm curious if that works in the case of 'hdfs' and 's3' protocol
because then I'd think it should work for us too.  Thanks!

On Mon, Apr 4, 2016 at 10:34 AM, Andrew Hulbert > wrote:

Yeah the only thing we will have to worry about is if the code
is written against java.io.File instead of some other URL lib.
At some point I guess we could dig in and look. I'll ask Jim
for more info and see if we can mock it up...while we're at it
we can do S3 or something too for another test.

On Mon, Apr 04, 2016 at 04:31:13PM +0200, Andrea Aime wrote:
> On Mon, Apr 4, 2016 at 4:30 PM, Andrea Aime
>
> wrote:
>
> > That said, I'm not sure this has ever been tried, not at
any level, but
> > especially with imageio-ext,
> >
>
> Sorry, mis-typed, I meant jai-imageio there
>
> Cheers
> Andrea
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> phone: +39 0584 962313 
> fax: +39 0584 1660272 
> mob: +39 339 8844549 
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>
> Le informazioni contenute in questo messaggio di posta
elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente
riservate. Il
> loro utilizzo è consentito esclusivamente al destinatario
del messaggio,
> per le finalità indicate nel messaggio stesso. Qualora
riceviate questo
> messaggio senza esserne il destinatario, Vi preghiamo
cortesemente di
> darcene notizia via e-mail e di procedere alla distruzione
del messaggio
> stesso, cancellandolo dal Vostro sistema. Conservare il
messaggio stesso,
> divulgarlo anche in parte, distribuirlo ad altri soggetti,
copiarlo, od
> utilizzarlo per finalità diverse, costituisce comportamento
contrario ai
> principi dettati dal D.Lgs. 196/2003.
>
>
>
> The information in this message and/or attachments, is
intended solely for
> the attention and use of the named addressee(s) and may be
confidential or
> proprietary in nature or covered by the provisions of
privacy act
> (Legislative Decree June, 30 2003, no.196 - Italy's New Data
Protection
> Code).Any use not in accord with its purpose, any
disclosure, reproduction,
> copying, distribution, or either dissemination, either whole
or partial, is
> strictly forbidden except previous formal approval of the named
> addressee(s). If you are not the intended recipient, please
contact
> immediately the sender by telephone, fax or e-mail and
delete the
> information in this message that has been received in error.
The sender
> does not give any warranty or accept liability as the
content, accuracy or
> completeness of sent messages and accepts no responsibility 
for changes

> made after 

Re: [Geoserver-devel] Custom URL protocol handling

[Jim Hughes]

Hi all,

As a little more context, we are looking for the most suitable way to 
HDFS-enable the existing raster plugins.

With some of the javax ImageIO SPI interfaces, it looked like we'd be 
close to being able to have a drop-in solution.  Otherwise, it looks 
like we may have to touch each plugin.

Thoughts?

Cheers,

Jim

On 04/01/2016 11:06 AM, Michael Matthews wrote:
> Hello Geoserver Devs,
>
> I'm trying to extend GeoTIFF support to be able to read image files
> directly from a Hadoop Distributed File System.  Our idea was to write
> ImageInputStream and ImageInputStreamSPI classes that would know how to
> handle the 'hdfs' protocol.
> When adding a GeoTIFF datastore through the GeoServer web UI, I received
> the error that 'hdfs://localhost:9000/sample.tif' is not a valid URL.
>
> How can I expand GeoServer's notion of a valid URL?
> Or, is there a better way to implement a hdfs interface?
>
> Optimally, we would like to extend this hdfs access functionality to
> NetCDF as well, but GeoTIFFs are our primary concern.
>
> Thank you,
> Michael Matthews
>
>
>
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel


--
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] PR Questions

[Jim Hughes]

Hi Andrew,

CCRi should have a little bit of the paperwork on hand.  In terms of 
committing, I think the first PR might have to go against master and 
then we'd have to ask for the backport.

Cheers,

Jim

On 03/02/2016 01:39 PM, Andrew Hulbert wrote:
> Hi all,
>
> I put up a PR for geojson encoding for list and map types.
>
> https://github.com/geoserver/geoserver/pull/1523
>
> Wanna make sure I get it all done right. My company is working on the
> contributor agreement.
>
> Should I make a separate PR for master (assuming it's worth of merge)?
>
> This is my first attempt at a commit. Lemme know what I did wrong!
>
> Thanks,
>
> Andrew
>
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] [Geotools-devel] Raster data source configuration in GeoServer

[Jim Hughes]

Hi Andrea,

Thanks for the further clarification.  While the url format is likely 
sufficient for many use cases, it is odd in the case we have.  We have a 
separate EditPanel for this, and we'll be contributing that to the 
GeoMesa community module in GeoServer.


It sounds like an extension would be to implement handling for 
additional objects (maybe a wrapper object containing a List of 
Parameters?), and that could be added to the general EditPanel code.  As 
Jody mentioned, that kind of thing would be a little R work...


Cheers,

Jim

On 02/06/2016 04:40 AM, Andrea Aime wrote:
On Thu, Feb 4, 2016 at 3:44 PM, Jim Hughes <jn...@ccri.com 
<mailto:jn...@ccri.com>> wrote:


Hi all,

Since this falls between GeoTools and GeoServer, I figured I'd
bump it and cross-post.

Phrased differently, "Does the CoverageFactory interface have the
same hooks for auto EditPanel generation as the DataStore interface?"

As the minute, in order to add a raster data source, we are
finding that we have to override GeoServer classes. For vector
data sources, we have never had to do that. Are we missing something?


You probably are? A GUI is automatically generated for rasters too.
Contrary to what Jody suggest, there are no parameters in a raster 
source, the Format class just accepts
a "Object source" without any description of what it could be, the 
list of "read parameters" is to be used

once the GridCoverageReader is already acquired, from the interface:

/**
 * Retrieve the parameter information for a {@link 
GridCoverageReader#read read} operation.

 */
@UML(identifier="getParameterInfo, numParameters", 
obligation=MANDATORY, specification=OGC_01004)

ParameterValueGroup getReadParameters();

The default DefaultCoverageStoreEditPanel assumes this object is a 
URL. If your source requires something

else then yes, you have to build your own panel

Cheers
Andrea

--
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o 
nel/i file/s allegato/i sono da considerarsi strettamente riservate. 
Il loro utilizzo è consentito esclusivamente al destinatario del 
messaggio, per le finalità indicate nel messaggio stesso. Qualora 
riceviate questo messaggio senza esserne il destinatario, Vi preghiamo 
cortesemente di darcene notizia via e-mail e di procedere alla 
distruzione del messaggio stesso, cancellandolo dal Vostro sistema. 
Conservare il messaggio stesso, divulgarlo anche in parte, 
distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità 
diverse, costituisce comportamento contrario ai principi dettati dal 
D.Lgs. 196/2003.


The information in this message and/or attachments, is intended solely 
for the attention and use of the named addressee(s) and may be 
confidential or proprietary in nature or covered by the provisions of 
privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New 
Data Protection Code).Any use not in accord with its purpose, any 
disclosure, reproduction, copying, distribution, or either 
dissemination, either whole or partial, is strictly forbidden except 
previous formal approval of the named addressee(s). If you are not the 
intended recipient, please contact immediately the sender by 
telephone, fax or e-mail and delete the information in this message 
that has been received in error. The sender does not give any warranty 
or accept liability as the content, accuracy or completeness of sent 
messages and accepts no responsibility  for changes made after they 
were sent or for other risks which arise as a result of e-mail 
transmission, viruses, etc.



---


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] [Geotools-devel] Raster data source configuration in GeoServer

[Jim Hughes]

Hi Jody,

Thanks.  That sounds like it squares with what Emilio had found.  I 
wanted to makes sure that we weren't overlooking something obvious.


Cheers,

Jim

On 02/05/2016 01:17 PM, Jody Garnett wrote:
I always figured that the raster work would be done in imageio-ext, or 
geotools as appropriate.

And any user interface work should be done as geoserver community module.

The raster Format API does provide connection parameters, which you 
can use to advertise your configuration options. You may need to work 
hard to make a user-interface dynamically from the connection 
parameters - but it would be a fun bit of RnD that would benefit all 
of geoserver.



--
Jody Garnett

On 4 February 2016 at 06:44, Jim Hughes <jn...@ccri.com 
<mailto:jn...@ccri.com>> wrote:


Hi all,

Since this falls between GeoTools and GeoServer, I figured I'd
bump it and cross-post.

Phrased differently, "Does the CoverageFactory interface have the
same hooks for auto EditPanel generation as the DataStore interface?"

As the minute, in order to add a raster data source, we are
finding that we have to override GeoServer classes. For vector
data sources, we have never had to do that. Are we missing something?

Cheers,

Jim


On 02/01/2016 09:25 AM, Emilio Lahr-Vivaz wrote:

Hello,

I'm a developer working on the GeoMesa project. We're trying to
add a custom raster data source and integrate it into GeoServer
2.8.x. However, we'd like to not extend any GeoServer classes out
of an abundance of caution around GPL licensing (we're Apache 2).
With vector data sources, all of the information regarding
configuration is pulled out of the getParametersInfo method -
perfect for us. However, it seems that for raster data sources,
any custom configuration has to be done by extending the
GeoServer StoreEditPanel - something we'd prefer to avoid.

One potential work-around we found is to register a custom URL
handler, and use it to parse our configuration. However, that
involves messy classloading issues, such that we would have to
install code in the JRE.

Are there any other extension points we're missing for
configuration of raster data sources?

Thanks,

Emilio Lahr-Vivaz



--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140


___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
<mailto:Geoserver-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/geoserver-devel




--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
GeoTools-Devel mailing list
geotools-de...@lists.sourceforge.net
<mailto:geotools-de...@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/geotools-devel




--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Raster data source configuration in GeoServer

[Jim Hughes]

Hi all,

Since this falls between GeoTools and GeoServer, I figured I'd bump it 
and cross-post.


Phrased differently, "Does the CoverageFactory interface have the same 
hooks for auto EditPanel generation as the DataStore interface?"


As the minute, in order to add a raster data source, we are finding that 
we have to override GeoServer classes.  For vector data sources, we have 
never had to do that.  Are we missing something?


Cheers,

Jim

On 02/01/2016 09:25 AM, Emilio Lahr-Vivaz wrote:

Hello,

I'm a developer working on the GeoMesa project. We're trying to add a 
custom raster data source and integrate it into GeoServer 2.8.x. 
However, we'd like to not extend any GeoServer classes out of an 
abundance of caution around GPL licensing (we're Apache 2). With 
vector data sources, all of the information regarding configuration is 
pulled out of the getParametersInfo method - perfect for us. However, 
it seems that for raster data sources, any custom configuration has to 
be done by extending the GeoServer StoreEditPanel - something we'd 
prefer to avoid.


One potential work-around we found is to register a custom URL 
handler, and use it to parse our configuration. However, that involves 
messy classloading issues, such that we would have to install code in 
the JRE.


Are there any other extension points we're missing for configuration 
of raster data sources?


Thanks,

Emilio Lahr-Vivaz


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140


___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] wicket7 branch merge - end of day - please respond

[Jim Hughes]

Hi Andrea,

Out of curiosity, is there a layer in the release/data which can be used 
to exercise the dyndimension plugin?  If so, we might be able to click 
around some.  Otherwise, we'll pencil in your name next to that module.


Thanks,

Jim

On 1/22/2016 2:16 PM, Andrea Aime wrote:

Hi,
just a quick addendum, I know that the "on/off" buttons in the jms 
clustering plugin config are not working, but
should not be too hard to fix, the aggregating, key and dynamic 
dymensions plugins do not actually require
specific enviroment, I have some familiarity with them but did not 
have enough time to check them.


Hopefully I can do some during the weekend about those, but yeah, 
generally speaking I'm feeling good about

merging back to the master branch.

Cheers
Andrea


On Fri, Jan 22, 2016 at 9:14 AM, Torben Barsballe 
> wrote:


Andrea made a build last night that everyone can try out - this
represents the current state of the branch:
http://demo.geo-solutions.it/share/wicket7-cs/m2


The JDBC

/LDAP


Authentication pages have not yet been tested. If anyone has an
appropriate environment configured, your help would be greatly
appreciated for a quick smoke test.


There are also a number of community modules that have not been
tested due to a lack ofan appropriate environment. While these do
not block the merge, it would be nice to get them tested:

The SOLR Community Module

has not been tested. If anyone has an appropriate environment
configured, your help would be greatly appreciated for a quick
smoke test.

The Key Authentication Community Module

has not yet been tested. If anyone has an appropriate environment
configured, your help would be greatly appreciated for a quick
smoke test.

The Aggregating DataStore Community Module


has not yet been tested. If anyone has an appropriate environment
configured, your help would be greatly appreciated for a quick
smoke test.

The Dynamic Dimension Defaults Community Module


has not yet been tested. If anyone has an appropriate environment
configured, your help would be greatly appreciated for a quick
smoke test.

Torben

On Fri, Jan 22, 2016 at 8:54 AM, Jody Garnett
> wrote:

Quick email - sprint is going really well (everyone worked
last night to test all the extensions, and the majority of the
community modules). See the spreadsheet


for live update. We are down to mop up work today, writing a
blog post thanking sponsors, updating screen snaps in docs.

Please Respond:  I would like to ask for a +1 from PSC and
community members on merging at end of day. This will allow
nightly builds to be used for subsequent community testing and
let the blog post link to fresh new docs on our website.
--
Jody Garnett


--
Site24x7 APM Insight: Get Deep Visibility into Application
Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective
actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/geoserver-devel




--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
___
Geoserver-devel 

Re: [Geoserver-devel] Wicket 7: error in logs when loading demo requests page

[Jim Hughes]

Hi Ben,

I'm pleased to report that Torben fixed that issues earlier today.

Cheers,

Jim

On 1/22/2016 9:31 PM, Ben Caradoc-Davies wrote:
> I see this error in the logs when loading the demo requests page using
> this build:
> http://demo.geo-solutions.it/share/wicket7-cs/m2/geoserver-2.9-SNAPSHOT-bin.zip
>
> The page itself seems to work perfectly.
>
> Kind regards,
> Ben.
>
> 2016-01-23 15:25:52,624 ERROR [java.JavaSerializer] - Error serializing
> object class org.geoserver.web.demo.DemoRequestsPage [object=[Page class
> = org.geoserver.web.demo.DemoRequestsPage, id = 33, render count = 1]]
> org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream$ObjectCheckException:
> The object type is not Serializable!
> A problem occurred while checking object with type:
> org.geoserver.platform.resource.DataDirectoryResourceStore
> Field hierarchy is:
> 33 [class=org.geoserver.web.demo.DemoRequestsPage, path=33]
>   private final org.geoserver.platform.resource.Resource
> org.geoserver.web.demo.DemoRequestsPage.demoDir
> [class=org.geoserver.platform.resource.FileSystemResourceStore$FileSystemResource]
> final org.geoserver.platform.resource.FileSystemResourceStore
> org.geoserver.platform.resource.FileSystemResourceStore$FileSystemResource.this$0
> [class=org.geoserver.platform.resource.DataDirectoryResourceStore]
> <- field that is causing the problem
>   at
> org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream.internalCheck(CheckingObjectOutputStream.java:364)
>   at
> org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream.check(CheckingObjectOutputStream.java:343)
>   at
> org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream.checkFields(CheckingObjectOutputStream.java:606)
>   at
> org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream.internalCheck(CheckingObjectOutputStream.java:542)
>   at
> org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream.check(CheckingObjectOutputStream.java:343)
>   at
> org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream.checkFields(CheckingObjectOutputStream.java:606)
>   at
> org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream.internalCheck(CheckingObjectOutputStream.java:542)
>   at
> org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream.check(CheckingObjectOutputStream.java:343)
>   at
> org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream.writeObjectOverride(CheckingObjectOutputStream.java:674)
>   at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:344)
>   at
> org.apache.wicket.serialize.java.JavaSerializer$SerializationCheckerObjectOutputStream.writeObjectOverride(JavaSerializer.java:271)
>   at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:344)
>   at
> org.apache.wicket.serialize.java.JavaSerializer.serialize(JavaSerializer.java:78)
>   at
> org.apache.wicket.pageStore.AbstractPageStore.serializePage(AbstractPageStore.java:133)
>   at
> org.apache.wicket.pageStore.DefaultPageStore.createSerializedPage(DefaultPageStore.java:281)
>   at
> org.apache.wicket.pageStore.DefaultPageStore.storePage(DefaultPageStore.java:61)
>   at
> org.apache.wicket.page.PageStoreManager$PersistentRequestAdapter.storeTouchedPages(PageStoreManager.java:403)
>   at
> org.apache.wicket.page.RequestAdapter.commitRequest(RequestAdapter.java:193)
>   at
> org.apache.wicket.page.AbstractPageManager.commitRequest(AbstractPageManager.java:76)
>   at
> org.apache.wicket.page.PageManagerDecorator.commitRequest(PageManagerDecorator.java:74)
>   at
> org.apache.wicket.page.PageAccessSynchronizer$2.commitRequest(PageAccessSynchronizer.java:270)
>   at org.apache.wicket.Application$3.onDetach(Application.java:1786)
>   at
> org.apache.wicket.request.cycle.RequestCycleListenerCollection$3.notify(RequestCycleListenerCollection.java:105)
>   at
> org.apache.wicket.request.cycle.RequestCycleListenerCollection$3.notify(RequestCycleListenerCollection.java:101)
>   at
> org.apache.wicket.util.listener.ListenerCollection$1.notify(ListenerCollection.java:120)
>   at
> org.apache.wicket.util.listener.ListenerCollection.reversedNotify(ListenerCollection.java:144)
>   at
> org.apache.wicket.util.listener.ListenerCollection.reversedNotifyIgnoringExceptions(ListenerCollection.java:113)
>   at
> org.apache.wicket.request.cycle.RequestCycleListenerCollection.onDetach(RequestCycleListenerCollection.java:100)
>   at
> org.apache.wicket.request.cycle.RequestCycle.onDetach(RequestCycle.java:645)
>   at
> org.apache.wicket.request.cycle.RequestCycle.detach(RequestCycle.java:594)
>   at
> org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:297)
>   at
> org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:261)
>   

Re: [Geoserver-devel] geoserver 2.8.2 preflight available

[Jim Hughes]

Hi all,

I've got a draft release blog post started for your review.

Cheers,

Jim

On 1/22/2016 9:52 PM, Jody Garnett wrote:

Preflight downloads available for your testing pleasure:

http://ares.boundlessgeo.com/geoserver/release/2.8.2
--
Jody Garnett


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140


___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Using Java 8 features

[Jim Hughes]

Hi Ben,

Fair enough.  I didn't see a roadmap/timeline for a 8.0 release.  I 
wonder if it is worth asking to see if a release is on the horizon.

Depending on how clever we get with the Java 8 features, it may be worth 
see if anything we do in Victoria can be contributed back.

Cheers,

Jim

On 01/04/2016 05:12 PM, Ben Caradoc-Davies wrote:
> Jim,
>
> while using Java 8 features in Wicket is an attractive idea, Wicket 
> 8.x is the development branch and only SNAPSHOTs are available:
> http://wicket.apache.org/start/wicket-8.x.html
>
> Unless we also want to become Wicket developers, I think we should 
> build GeoServer on current supported Wicket (7.x releases).
>
> Wicket 7.0 was only released in July:
> http://wicket.apache.org/news/2015/07/28/wicket-7.0-released.html
>
> Kind regards,
> Ben.
>
> On 05/01/16 10:57, Jim Hughes wrote:
>> Hi all,
>>
>> As a quick question/follow-up, if the GeoServer build already users Java
>> 8, could we bump to Wicket 8?
>>
>>  From what I can tell, the Wicket version is tied to the version of
>> Java.  Consequently, Wicket 8 may have some Lambda work we could 
>> leverage.
>>
>> Worst case, given GeoServer's size, if we end up with a few hand-rolled
>> helper functions, it won't be the end of the world.
>>
>> Cheers,
>>
>> Jim
>>
>> On 01/01/2016 05:35 AM, Andrea Aime wrote:
>>> Hi Brad,
>>> yes, lambdas are on the sprint upgrade menu in order to reduce
>>> boilerplate.
>>> I believe Jim (cc'ed) wanted to look into them, check the thread
>>> "Preparing for the Wicket upgrade sprint" in this list for details.
>>>
>>> What I believe we want to have in time for the code sprint (Jan 
>>> 18th) is
>>> some discussion and guidance about which path to follow, like
>>> rolling our own, depending on one of the existing attempts to leverage
>>> lambdas in Wicket models/actions/validators or a hybrid approach.
>>> And if it's rolling our own, then yep, some code to use when we start
>>> migrating existing pages to it.
>>>
>>> Cheers
>>> Andrea
>>>
>>> -- 
>>> ==
>>> GeoServer Professional Services from the experts! Visit
>>> http://goo.gl/it488V for more information.
>>> ==
>>>
>>> *_Geosolutions' Winter Holidays from 24/12 to 6/1_*
>>>
>>> Ing. Andrea Aime
>>> @geowolf
>>> Technical Lead
>>>
>>> GeoSolutions S.A.S.
>>> Via Poggio alle Viti 1187
>>> 55054  Massarosa (LU)
>>> Italy
>>> phone: +39 0584 962313 <tel:%2B39%200584%20962313>
>>> fax: +39 0584 1660272 <tel:%2B39%200584%201660272>
>>> mob: +39  339 8844549 <tel:%2B39%20%C2%A0339%208844549>
>>>
>>> http://www.geo-solutions.it
>>> http://twitter.com/geosolutions_it
>>>
>>> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>>>
>>> Le informazioni contenute in questo messaggio di posta elettronica e/o
>>> nel/i file/s allegato/i sono da considerarsi strettamente riservate.
>>> Il loro utilizzo è consentito esclusivamente al destinatario del
>>> messaggio, per le finalità indicate nel messaggio stesso. Qualora
>>> riceviate questo messaggio senza esserne il destinatario, Vi preghiamo
>>> cortesemente di darcene notizia via e-mail e di procedere alla
>>> distruzione del messaggio stesso, cancellandolo dal Vostro sistema.
>>> Conservare il messaggio stesso, divulgarlo anche in parte,
>>> distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità
>>> diverse, costituisce comportamento contrario ai principi dettati dal
>>> D.Lgs. 196/2003.
>>>
>>> The information in this message and/or attachments, is intended solely
>>> for the attention and use of the named addressee(s) and may be
>>> confidential or proprietary in nature or covered by the provisions of
>>> privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New
>>> Data Protection Code).Any use not in accord with its purpose, any
>>> disclosure, reproduction, copying, distribution, or either
>>> dissemination, either whole or partial, is strictly forbidden except
>>> previous formal approval of the named addressee(s). If you are not the
>>> intended recipient, please contact immediately the sender by
>>> telephone, fax or e-mail and delete the information in this message
>>> that has been received in error. The sender does not give any warranty
>>> or accept liability as the content, accur

Re: [Geoserver-devel] Using Java 8 features

[Jim Hughes]

Hi all,

As a quick question/follow-up, if the GeoServer build already users Java 
8, could we bump to Wicket 8?


From what I can tell, the Wicket version is tied to the version of 
Java.  Consequently, Wicket 8 may have some Lambda work we could leverage.


Worst case, given GeoServer's size, if we end up with a few hand-rolled 
helper functions, it won't be the end of the world.


Cheers,

Jim

On 01/01/2016 05:35 AM, Andrea Aime wrote:

Hi Brad,
yes, lambdas are on the sprint upgrade menu in order to reduce 
boilerplate.

I believe Jim (cc'ed) wanted to look into them, check the thread
"Preparing for the Wicket upgrade sprint" in this list for details.

What I believe we want to have in time for the code sprint (Jan 18th) is
some discussion and guidance about which path to follow, like
rolling our own, depending on one of the existing attempts to leverage
lambdas in Wicket models/actions/validators or a hybrid approach.
And if it's rolling our own, then yep, some code to use when we start
migrating existing pages to it.

Cheers
Andrea

--
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==

*_Geosolutions' Winter Holidays from 24/12 to 6/1_*

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313 
fax: +39 0584 1660272 
mob: +39  339 8844549 

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o 
nel/i file/s allegato/i sono da considerarsi strettamente riservate. 
Il loro utilizzo è consentito esclusivamente al destinatario del 
messaggio, per le finalità indicate nel messaggio stesso. Qualora 
riceviate questo messaggio senza esserne il destinatario, Vi preghiamo 
cortesemente di darcene notizia via e-mail e di procedere alla 
distruzione del messaggio stesso, cancellandolo dal Vostro sistema. 
Conservare il messaggio stesso, divulgarlo anche in parte, 
distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità 
diverse, costituisce comportamento contrario ai principi dettati dal 
D.Lgs. 196/2003.


The information in this message and/or attachments, is intended solely 
for the attention and use of the named addressee(s) and may be 
confidential or proprietary in nature or covered by the provisions of 
privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New 
Data Protection Code).Any use not in accord with its purpose, any 
disclosure, reproduction, copying, distribution, or either 
dissemination, either whole or partial, is strictly forbidden except 
previous formal approval of the named addressee(s). If you are not the 
intended recipient, please contact immediately the sender by 
telephone, fax or e-mail and delete the information in this message 
that has been received in error. The sender does not give any warranty 
or accept liability as the content, accuracy or completeness of sent 
messages and accepts no responsibility  for changes made after they 
were sent or for other risks which arise as a result of e-mail 
transmission, viruses, etc.



---


--
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Security propagation in chained WPS

[Jim Hughes]

Hi Andrea,

Thanks again for the pointer.  We debugged the issue, and it seems to 
have been an error in how we configured the security chain in our dev 
environment.


Thanks again; all is working!

Jim

On 10/30/2015 09:27 AM, Jim Hughes wrote:

Hi Andrea,

Thanks for the fast reply.  Since we only have a few chained WPSes and 
this is complex, it may take us a few days to check things out.


If the issue is still in the 2.8/2.9 series, I'll do my best to report 
back with more info and add some unit tests and/or see if I can sort 
some fixes.


Thanks again,

Jim

On 10/30/2015 03:46 AM, Andrea Aime wrote:
On Thu, Oct 29, 2015 at 10:22 PM, Jim Hughes <jn...@ccri.com 
<mailto:jn...@ccri.com>> wrote:


Hi all,

I'm working with a secured datastore (GeoMesa) which returns
different
result sets based on user credentials.  As we are using the GeoServer
Heatmap WPS in an SLD, the user credentials are propagated just fine.

We are seeing an issue when we try to chain together that heatmap WPS
with the import WPS.  The user credentials are not passed to the
heatmap
WPS, and consequently, no features are returned.

I'm curious to know where in the code this may be handled (for my own
curiosity).  From what I understand, there have been some major
updates
to WPS in 2.7/2.8, so I'm fine with a suggestion to upgrade.


Hi Jim,
processes are running in thread pools, passing thread local variables 
(such as
the authentication) into the thread pool and cleaning them out is the 
job

ThreadLocalTransfer implementors, in particular, authentication
is tranferred by AuthenticationThreadLocalTransfer:

https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/threadlocals/AuthenticationThreadLocalTransfer.java

This class is rather old though, 2 and a half years, but judging by 
the first commit,
there is no integration test covering the use case end to end, just a 
lot of unit ones, so it might

have regressed recently.

Cheers
Andrea

--
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica 
e/o nel/i file/s allegato/i sono da considerarsi strettamente 
riservate. Il loro utilizzo è consentito esclusivamente al 
destinatario del messaggio, per le finalità indicate nel messaggio 
stesso. Qualora riceviate questo messaggio senza esserne il 
destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail 
e di procedere alla distruzione del messaggio stesso, cancellandolo 
dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche 
in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo 
per finalità diverse, costituisce comportamento contrario ai principi 
dettati dal D.Lgs. 196/2003.


The information in this message and/or attachments, is intended 
solely for the attention and use of the named addressee(s) and may be 
confidential or proprietary in nature or covered by the provisions of 
privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New 
Data Protection Code).Any use not in accord with its purpose, any 
disclosure, reproduction, copying, distribution, or either 
dissemination, either whole or partial, is strictly forbidden except 
previous formal approval of the named addressee(s). If you are not 
the intended recipient, please contact immediately the sender by 
telephone, fax or e-mail and delete the information in this message 
that has been received in error. The sender does not give any 
warranty or accept liability as the content, accuracy or completeness 
of sent messages and accepts no responsibility  for changes made 
after they were sent or for other risks which arise as a result of 
e-mail transmission, viruses, etc.



---




--


___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


--
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Security propagation in chained WPS

[Jim Hughes]

Hi Andrea,

Thanks for the fast reply.  Since we only have a few chained WPSes and 
this is complex, it may take us a few days to check things out.


If the issue is still in the 2.8/2.9 series, I'll do my best to report 
back with more info and add some unit tests and/or see if I can sort 
some fixes.


Thanks again,

Jim

On 10/30/2015 03:46 AM, Andrea Aime wrote:
On Thu, Oct 29, 2015 at 10:22 PM, Jim Hughes <jn...@ccri.com 
<mailto:jn...@ccri.com>> wrote:


Hi all,

I'm working with a secured datastore (GeoMesa) which returns different
result sets based on user credentials.  As we are using the GeoServer
Heatmap WPS in an SLD, the user credentials are propagated just fine.

We are seeing an issue when we try to chain together that heatmap WPS
with the import WPS.  The user credentials are not passed to the
heatmap
WPS, and consequently, no features are returned.

I'm curious to know where in the code this may be handled (for my own
curiosity).  From what I understand, there have been some major
updates
to WPS in 2.7/2.8, so I'm fine with a suggestion to upgrade.


Hi Jim,
processes are running in thread pools, passing thread local variables 
(such as

the authentication) into the thread pool and cleaning them out is the job
ThreadLocalTransfer implementors, in particular, authentication
is tranferred by AuthenticationThreadLocalTransfer:

https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/threadlocals/AuthenticationThreadLocalTransfer.java

This class is rather old though, 2 and a half years, but judging by 
the first commit,
there is no integration test covering the use case end to end, just a 
lot of unit ones, so it might

have regressed recently.

Cheers
Andrea

--
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o 
nel/i file/s allegato/i sono da considerarsi strettamente riservate. 
Il loro utilizzo è consentito esclusivamente al destinatario del 
messaggio, per le finalità indicate nel messaggio stesso. Qualora 
riceviate questo messaggio senza esserne il destinatario, Vi preghiamo 
cortesemente di darcene notizia via e-mail e di procedere alla 
distruzione del messaggio stesso, cancellandolo dal Vostro sistema. 
Conservare il messaggio stesso, divulgarlo anche in parte, 
distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità 
diverse, costituisce comportamento contrario ai principi dettati dal 
D.Lgs. 196/2003.


The information in this message and/or attachments, is intended solely 
for the attention and use of the named addressee(s) and may be 
confidential or proprietary in nature or covered by the provisions of 
privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New 
Data Protection Code).Any use not in accord with its purpose, any 
disclosure, reproduction, copying, distribution, or either 
dissemination, either whole or partial, is strictly forbidden except 
previous formal approval of the named addressee(s). If you are not the 
intended recipient, please contact immediately the sender by 
telephone, fax or e-mail and delete the information in this message 
that has been received in error. The sender does not give any warranty 
or accept liability as the content, accuracy or completeness of sent 
messages and accepts no responsibility  for changes made after they 
were sent or for other risks which arise as a result of e-mail 
transmission, viruses, etc.



---


--
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] Security propagation in chained WPS

[Jim Hughes]

Hi all,

I'm working with a secured datastore (GeoMesa) which returns different 
result sets based on user credentials.  As we are using the GeoServer 
Heatmap WPS in an SLD, the user credentials are propagated just fine.

We are seeing an issue when we try to chain together that heatmap WPS 
with the import WPS.  The user credentials are not passed to the heatmap 
WPS, and consequently, no features are returned.

I'm curious to know where in the code this may be handled (for my own 
curiosity).  From what I understand, there have been some major updates 
to WPS in 2.7/2.8, so I'm fine with a suggestion to upgrade.

Thanks in advance,

Jim

--
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Asking for new vector tiles community module

[Jim Hughes]

Gabriel,

First, I'm excited see vector tile output for GeoServer, so +1 for that!

From an incredibly quick read through, I have one high-level question.  
Is the topology processing which is part of this diff something which 
may find a better, more general home or is it specific to GeoJSON vector 
tiles?  I suppose I get curious when I see Point, Linestring, etc. 
classes needing to be written.


Thanks,

Jim

On 06/19/2015 01:41 PM, Gabriel Roldan wrote:

Hello all,

at Boundless we're working on GeoServer/GWC support for Vector Tiles, 
hence I'm looking for approval to add a new community module to master 
in the interest of making the work available for everyone.


TL;DR version:

We'll be producing vector maps in TopoJSON, GeoJSON, and Mapbox PBF 
formats through the WMS, so that these vector maps can be produced 
for any map dimensions / CRS combination, leaving the slicing into 
specific grids to GWC, or the client apps requesting the map tiles to 
the WMS directly where they're dynamically generated.
The WMS map output format(s) will allow a certain level of control 
over geometry simplification either through the dpi wms argument or 
other custom parameter, yet to be determined, and over the number of 
returned features by respecting the layer's SLD 
min/maxScaleDenominator + filter rules.


Work is being conducted on this branch 
https://github.com/groldan/geoserver/tree/vectortiles
At a glance: 
 https://github.com/groldan/geoserver/compare/master...vectortiles


Full story:

There are different formats in which vector tiles can be encoded, none 
of which is an industry or de-facto standard:


Mapbox Vector Tiles 
https://github.com/mapbox/vector-tile-spec/tree/master/1.0.1: 
Protocol Buffers based. No support for it in OL3.
TopoJSON 
https://github.com/mbostock/topojson-specification/blob/master/README.md: 
JSON arc-poly topology, points encoded inline. There's a large OSM 
dataset in this format and OL3 has support for it 
http://openlayers.org/en/v3.5.0/examples/tile-vector.html
GeoJSON http://geojson.org/geojson-spec.html: the good and old 
GeoJSON format can also be used as vector tiles. OL3 can be set up to 
use it as easily as it does with TopoJSON.


Now, each format has its pros and cons. The common denominator though, 
is that all of them can fulfill the requirement of producing geometry 
generalized versions of raw feature data plus alphanumeric attribtues.
The geometry generalization is key in order to control the resulting 
tile file size, and the resource consumption on the map client.


On top of that, we want to add other requirements:

* Dynamically generate vector tiles: can do with GeoServer WMS, 
regardless of map/screen dimensions and requested projection.
* Control over level of geometry generalization: can do with 
GeoServer's WMS standard DPI parameter, or other format specific 
parameters
* Control on number of features produced by zoom level: can do with 
SLD FeatureTypeStyle Rules and min/maxScaleDenominators
* Leverage the current software stack and existing infrastructure as 
much as possible: Let GWC request and cache vector tiles in the 
appropriate tile size/resolution and projection. Leverage OL3's 
flexibility to load tiles from TMS, WMS, WMS-C, etc.


Vector Tile Format break down:


MapBox Vector Tiles
---
Pros: compresses a bit better than the JSON text based formats with 
gzip compression.
Cons: non human readable. Lack of support in OL3 so far. Limited 
control over resolution. Tied to Web Mercator projection by MapBox's 
spec, but we intend to overcome that silly limitation


TopoJSON:

Pros: human readable. Allows to share common edges between adjacent 
geometries.
Cons: The edge sharing is easy to implement from raw OSM data which in 
itself is a topology. For non topology based data, figuring out the 
common edges is a slow and resource consuming process. The format can 
be written with duplicated arcs but kind of defeats its purpose. Yet 
for the time being we're producing it without the extra complexity 
that computing common edges implies. Another con is that it can't be 
produced in a streaming way, since the topology needs to be built in 
memory before encoding.


GeoJSON:
--
Pros: human readable. Streaming.
Cons: _may_ compress a bit worse than TopoJSON. Yet to be determined. 
It should compress worse than TopoJSON when the later is encoded with 
shared edges.


OL3:
--
* It'd be good if OL could reuse vector tiles of higher resolutions in 
lower resolution zoom levels. (already possible with custom grids)
* It'd be good if OL could merge the geometries for the same features 
coming from different tiles, as they may be clipped to tile bounds.
* OL support for MapBox tiles is not yet there, nor part of this 
effort, but it'll be there at some point


--

Gabriel Roldán
Software Developer | Boundless http://boundlessgeo.com/
grol...@boundlessgeo.com 

Re: [Geoserver-devel] Adding CQL filtering at the layer level configuration

[Jim Hughes]

Andrea,

This is a technical comment/question rather than a note about the main 
proposal.  (The proposal overall seems sensible to me.)


As you work with and store the ECQL filter, are you going to need 
ECQL.toFilter/ECQL.toCQL to be inverses?  I've seen a few cases where 
that doesn't work out completely.  (And I've tried to help submit 
patches as I learn about them.)


Anyhow, maybe that's not necessary; figured I'd mention it.

Cheers,

Jim

On 05/20/2015 05:43 AM, Andrea Aime wrote:

Hi,
in this mail I'm proposing we resurrect an old functinality we had at 
the 1.7.x times,

filtering layers by a user specified filter.

The FeatureTypeInfo filter field is indeed still there:
https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/catalog/FeatureTypeInfo.java#L61
but the code around it is kind of lacking, and need some massaging and 
deep testing to make
sure it actually works, since nothing in that area has been touched in 
several years.


GUI wise we need a way to edit the filters, which I'm proposing is 
going to be a simple text field for the moment,
that will show up below the attribute list, and which will validate 
checking both syntax and proper usage of

existing attributes in the layer.

Persistence wise, we need to have XStream store the Filter (right now 
there are no converters for them, which
would make for a non useful storage), which I'm proposing to store as 
ECQL too.


We'll then have to verify that the filtering machinery works at the 
GeoServerFeatureSource level, and that

it mixes well with user, style and security filters.

The impetus to work on this originates from simplifying and at the 
same time generalizing the SORL store

usage (see related mail in GeoTools devel),
dropping the attribute based layer mapping, and replacing with a more 
general CQL filter that
will also allow the same document to show up in multiple layers, but 
the functionality is general and will

be useful in other cases too.

Cheers
Andrea

--
==
Meet us at the INSPIRE Conference in Lisbon 25-29 May 2015! Visit 
http://goo.gl/WHKDXT for more information.

==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o 
nel/i file/s allegato/i sono da considerarsi strettamente riservate. 
Il loro utilizzo è consentito esclusivamente al destinatario del 
messaggio, per le finalità indicate nel messaggio stesso. Qualora 
riceviate questo messaggio senza esserne il destinatario, Vi preghiamo 
cortesemente di darcene notizia via e-mail e di procedere alla 
distruzione del messaggio stesso, cancellandolo dal Vostro sistema. 
Conservare il messaggio stesso, divulgarlo anche in parte, 
distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità 
diverse, costituisce comportamento contrario ai principi dettati dal 
D.Lgs. 196/2003.


The information in this message and/or attachments, is intended solely 
for the attention and use of the named addressee(s) and may be 
confidential or proprietary in nature or covered by the provisions of 
privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New 
Data Protection Code).Any use not in accord with its purpose, any 
disclosure, reproduction, copying, distribution, or either 
dissemination, either whole or partial, is strictly forbidden except 
previous formal approval of the named addressee(s). If you are not the 
intended recipient, please contact immediately the sender by 
telephone, fax or e-mail and delete the information in this message 
that has been received in error. The sender does not give any warranty 
or accept liability as the content, accuracy or completeness of sent 
messages and accepts no responsibility for changes made after they 
were sent or for other risks which arise as a result of e-mail 
transmission, viruses, etc.



---


--
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y


___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats 

Re: [Geoserver-devel] Adding CQL filtering at the layer level configuration

[Jim Hughes]

The times I've run into it, ECQL.toCQL has produced a string which 
cannot be parsed by ECQL.toFilter.


If you carried around the original input string, you'd be set.  For us, 
we've played rewriting filters and that's when things have gotten exciting.


Cheers,

JIm

On 05/20/2015 02:01 PM, Andrea Aime wrote:
On Wed, May 20, 2015 at 7:56 PM, Jim Hughes jn...@ccri.com 
mailto:jn...@ccri.com wrote:


Andrea,

This is a technical comment/question rather than a note about the
main proposal.  (The proposal overall seems sensible to me.)

As you work with and store the ECQL filter, are you going to need
ECQL.toFilter/ECQL.toCQL to be inverses? I've seen a few cases
where that doesn't work out completely.  (And I've tried to help
submit patches as I learn about them.)


I'm aware, but I guess we'll cross that river when necessary. I don't 
think it's a big deal if the syntax changes, provided

the semantic of the filter remains the same. Or not?

Cheers
Andrea


--
==
Meet us at the INSPIRE Conference in Lisbon 25-29 May 2015! Visit 
http://goo.gl/WHKDXT for more information.

==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o 
nel/i file/s allegato/i sono da considerarsi strettamente riservate. 
Il loro utilizzo è consentito esclusivamente al destinatario del 
messaggio, per le finalità indicate nel messaggio stesso. Qualora 
riceviate questo messaggio senza esserne il destinatario, Vi preghiamo 
cortesemente di darcene notizia via e-mail e di procedere alla 
distruzione del messaggio stesso, cancellandolo dal Vostro sistema. 
Conservare il messaggio stesso, divulgarlo anche in parte, 
distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità 
diverse, costituisce comportamento contrario ai principi dettati dal 
D.Lgs. 196/2003.


The information in this message and/or attachments, is intended solely 
for the attention and use of the named addressee(s) and may be 
confidential or proprietary in nature or covered by the provisions of 
privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New 
Data Protection Code).Any use not in accord with its purpose, any 
disclosure, reproduction, copying, distribution, or either 
dissemination, either whole or partial, is strictly forbidden except 
previous formal approval of the named addressee(s). If you are not the 
intended recipient, please contact immediately the sender by 
telephone, fax or e-mail and delete the information in this message 
that has been received in error. The sender does not give any warranty 
or accept liability as the content, accuracy or completeness of sent 
messages and accepts no responsibility for changes made after they 
were sent or for other risks which arise as a result of e-mail 
transmission, viruses, etc.



---


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] GeoTools / GeoServer Meeting 2015-05-12

[Jim Hughes]

Hi Jody, Tyler,

Here's what happened with GeoMesa, EPSG, and hsqldb...

For simplicity, we've by and large restricted our early attention to 
EPSG:4326.  For GeoMesa, we tried out gt-epsg-hsql* and gt-epsg-wkt.  At 
the moment, we boldly depend on neither.  Ingest code and the code 
distributed to Accumulo servers hasn't needed the EPSG database.  
Otherwise, when deployed with GeoServer, an appropriate database is 
available.


As we entered the Eclipse CQ for gt-epsg-hsql, we must have listed 
hsqldb as a transitive dependency.  Finding version 2.3.0 in Ipzilla 
(https://dev.eclipse.org/ipzilla/show_bug.cgi?id=8727), we piggy-backed 
on it.


As a note, we did manage the transitive dependency on hsqldb in our 
pom.  We did not run into any problems doing that.  (No promises Tyler, 
but specifying the hsqldb version in GeoGig's pom may be sufficient.)


Anyhow, it looks like GeoMesa can remove hsqldb from our dependencies 
management...


Cheers,

Jim

On 05/13/2015 02:17 PM, Jody Garnett wrote:
Well keep us informed, if you can Jim can submit pull requests they 
can be reviewed in due course.


--
Jody Garnett

On 13 May 2015 at 01:47, Tyler Battle tbat...@boundlessgeo.com 
mailto:tbat...@boundlessgeo.com wrote:


As far as GeoGig's LocationTech IP review goes, the only
dependency (so far) from GeoTools that we need bumped is hsqldb
2.2.8 - 2.3

I haven't tried it, so I'm not sure if it'll just work or not.
Actually, Jim, did GeoMesa just force it to use 2.3?

I'm sure there will be others, but we're still waiting on the IP team.



On 12 May 2015 at 15:23, Jody Garnett jody.garn...@gmail.com
mailto:jody.garn...@gmail.com wrote:

A couple of things Jim:

- Can you confirm master is working for you :)
- We should touch base with Tyler to see if there are any
other dependencies we need to update before cutting a 14.x
milestone
- I did not implement normalize() and normalize(Matrix) as I
was not confident on how to implement the SVD normalization
described using the new matrix library. If you could figure
out an example we could actually be method compatible.

I need to make a small note on the Upgrade
http://docs.geotools.org/latest/userguide/welcome/upgrade.html
page mentioning that GeneralMatrix has been rewritten, but
should be method compatible.




--
Jody Garnett

On 12 May 2015 at 15:02, Jim Hughes jn...@ccri.com
mailto:jn...@ccri.com wrote:

Ben, Thanks for the notes.

Jody, thanks for finishing up the vecmath work; it looks
good to me.  (I
think I found an used variable.)  If there's anything
outstanding for
the vecmath work, I might be able to find a few more hours.

For the 14-M0 release, let me know what I can do.

Cheers,

Jim

On 05/12/2015 03:59 PM, Ben Caradoc-Davies wrote:
 GeoTools / GeoServer Meeting 2015-05-12
 ===

 Attending
 -

 Ben Caradoc-Davies
 Jody Garnett
 Kevin Smith
 Jukka Rahkonen
 Andrea Aime
 Torben Barsballe

 Agenda
 --

 - Jira migration
 - Release
 - Pull Request Roundup

 Actions
 ---

 - Torben / Kevin: May 18th: GeoTools 13.1 / GeoServer
2.7.1: Conflict
 with public holiday ... so tuesday :)
 - Jody / Jim: May 21st: GeoTools 14-M0 / GeoServer
2.8-M0 Milestone

 Actions from last meeting
 -

 - Ben: Follow up with Niels about complex feature
parsing pull request
 (GeoTools #406) [DONE by Jody]
 - Jody: vecmath merge and co-ordinate with Jim about
Milestone release
 - Andrea: follow up with Harrison about Jira migration
[DONE]
 - Andrea: feature specific blog posts for geoserver [TBD]
 - Andrea: Follow up with Mike about #1025 [Done
personally, Mike did not
 answer]
 - Kevin: To follow up with Boundless about #1005
 - Kevin: Look at GeoServer #707 (Separate panels for
layer defaults and
 general caching options), which was held up by freeze

 Jira migration
 --

 - mailing list notifications :)
 - can now close/resolve issues (and any subsequent
script updates will
 only touch open issues)
 - github integration attempted but not working

Re: [Geoserver-devel] GeoTools / GeoServer Meeting 2015-05-12

[Jim Hughes]

Ben, Thanks for the notes.

Jody, thanks for finishing up the vecmath work; it looks good to me.  (I 
think I found an used variable.)  If there's anything outstanding for 
the vecmath work, I might be able to find a few more hours.

For the 14-M0 release, let me know what I can do.

Cheers,

Jim

On 05/12/2015 03:59 PM, Ben Caradoc-Davies wrote:
 GeoTools / GeoServer Meeting 2015-05-12
 ===

 Attending
 -

 Ben Caradoc-Davies
 Jody Garnett
 Kevin Smith
 Jukka Rahkonen
 Andrea Aime
 Torben Barsballe

 Agenda
 --

 - Jira migration
 - Release
 - Pull Request Roundup

 Actions
 ---

 - Torben / Kevin: May 18th: GeoTools 13.1 / GeoServer 2.7.1: Conflict
 with public holiday ... so tuesday :)
 - Jody / Jim: May 21st: GeoTools 14-M0 / GeoServer 2.8-M0 Milestone

 Actions from last meeting
 -

 - Ben: Follow up with Niels about complex feature parsing pull request
 (GeoTools #406) [DONE by Jody]
 - Jody: vecmath merge and co-ordinate with Jim about Milestone release
 - Andrea: follow up with Harrison about Jira migration [DONE]
 - Andrea: feature specific blog posts for geoserver [TBD]
 - Andrea: Follow up with Mike about #1025 [Done personally, Mike did not
 answer]
 - Kevin: To follow up with Boundless about #1005
 - Kevin: Look at GeoServer #707 (Separate panels for layer defaults and
 general caching options), which was held up by freeze

 Jira migration
 --

 - mailing list notifications :)
 - can now close/resolve issues (and any subsequent script updates will
 only touch open issues)
 - github integration attempted but not working
 - last check difference in indicated internal version number was the
 bottle neck
 - AA tried to grab an XML dump; did not work

 Release Schedule
 

 https://github.com/geoserver/geoserver/wiki/Release-Schedule

 May 18th: GeoTools 13.1 / GeoServer 2.7.1
 - Torben / Kevin? Conflict with public holiday ... so tuesday :)

 May 21st: GeoTools 14-M0 / GeoServer 2.8-M0 Milestone
 - Jody / Jim :)

 Pull Request Roundup
 

 https://github.com/geotools/geotools/pull/836 Revised matrix work
 - ready?

 https://github.com/geotools/geotools/pull/838 NPE featureTypeList Operations
 - held up on sample data

 https://github.com/geotools/geotools/pull/816 Renco indexing
 - aaime is a bit stuck as previous merge did not quite work out
 - fix (and initial merge) need more careful attention then time allows,
 requires a windows machine (for JDBC-ODBC bridge)

 https://github.com/geoserver/geoserver/pull/1044 Geofence: REST API
 - looks to be waiting for review
 - Emanuele to review
 - jody can do a quick review

 Disabled multicast node discovery in HazelcastTest #1051
 https://github.com/geoserver/geoserver/pull/1051
 - merged

 https://github.com/geoserver/geoserver/pull/707 separate panels for
 layer defaults
 - kevin to rebase

 - Ben mentioned:
 JVM crash in gt-ogr-bridj
 OGRDataStoreTest.testAttributesWritingSqliteFromUpperCaseAttributes on
 debian/sid
 https://osgeo-org.atlassian.net/browse/GEOT-5101




--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] Import Process

[Jim Hughes]

Hi all,

We were working with some WPS process chaining recently.  While looking 
at the Import Process, we noticed that there was a TODO for a supporting 
store creation here: 
https://github.com/geoserver/geoserver/blob/master/src/extension/wps/wps-core/src/main/java/org/geoserver/wps/gs/ImportProcess.java#L142.

Anyhow, for our immediate need, we ended up wrapping and delegating to 
the GeoServer Import Process to cover the lack of store creation.  I 
think satisfying the todo may require a few lines, and it likely really 
close to what we already did.

Any objections about a quick PR for that todo?  Also, if there are any 
notes, feel free to pass those on.

Cheers,

Jim

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] GeoMesa community module

[Jim Hughes]

Thanks Jody, Andrea,

Awesome, I'll write back when I have a PR for the GeoMesa code which 
needs to move over.


Cheers,

Jim

On 03/02/2015 03:58 PM, Jody Garnett wrote:
We went over the basic this way is up overview during the OSGeo code 
sprint :)


Jim I am on Skype or IRC if you need a hand getting going...
--
Jody

--
Jody Garnett

On 2 March 2015 at 12:56, Andrea Aime andrea.a...@geo-solutions.it 
mailto:andrea.a...@geo-solutions.it wrote:


On Mon, Mar 2, 2015 at 9:37 PM, Jim Hughes jn...@ccri.com
mailto:jn...@ccri.com wrote:

Hi Jody,

Thanks.  For community module additions, should I be
submitting PRs or just updating my little slice of the
community directory?


Normally the first contribution is done as a PR, if it's fine,
 and you have read the developer guide and say so,
and so on, you normally get commit access in order to maintain
your community module.

If instead the PR is a long back and forth and/or you start
questioning the way the project does things
before even having commit access... uh... things might get long ;-)
(mind, not saying you are going to do that, or that you have done
anything like that so far, because
you did not, just exemplifying for the readers what might give us
doubts about giving out commit access)

Cheers
Andrea

-- 
==

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313 tel:%2B39%200584%20962313
fax: +39 0584 1660272 tel:%2B39%200584%201660272
mob: +39  339 8844549 tel:%2B39%20%C2%A0339%208844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica
e/o nel/i file/s allegato/i sono da considerarsi strettamente
riservate. Il loro utilizzo è consentito esclusivamente al
destinatario del messaggio, per le finalità indicate nel messaggio
stesso. Qualora riceviate questo messaggio senza esserne il
destinatario, Vi preghiamo cortesemente di darcene notizia via
e-mail e di procedere alla distruzione del messaggio stesso,
cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti,
copiarlo, od utilizzarlo per finalità diverse, costituisce
comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended
solely for the attention and use of the named addressee(s) and may
be confidential or proprietary in nature or covered by the
provisions of privacy act (Legislative Decree June, 30 2003,
no.196 - Italy's New Data Protection Code).Any use not in accord
with its purpose, any disclosure, reproduction, copying,
distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please
contact immediately the sender by telephone, fax or e-mail and
delete the information in this message that has been received in
error. The sender does not give any warranty or accept liability
as the content, accuracy or completeness of sent messages and
accepts no responsibility  for changes made after they were sent
or for other risks which arise as a result of e-mail transmission,
viruses, etc.


---




--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] GeoMesa community module

[Jim Hughes]

Thanks Jody,

Apologies for the long, I've submitted my OSGeo paperwork and my github 
id is jnh5y.


I'd like to provide documentation for the module.  How can I submit that 
info?


As for fetching the GeoMesa datastore from a public repo, the answer is 
yes.  GeoMesa artifacts are available from LocationTech's Nexus repo.  
There is a subtle issue with some versions of Maven and that server at 
the minute.


On the other hand, the GeoMesa GeoServer module is intended to be the 
home for code which provides additional functionality to GeoServer 
related to GeoMesa GeoTools datatores.


Thanks in advance,

Jim

On 02/13/2015 10:52 AM, Jody Garnett wrote:

Thanks Jim,

+1 and welcome to GeoServer :)

One technical question - for this community module ... is it able to 
fetch the geomesa datastore from a public repository?


As per the developers guide the next step is to send in contributor 
agreeements to OSGeo (see committing 
http://docs.geoserver.org/latest/en/developer/policies/committing.html#comitting). 
When that is done send me your github ID we can set you up.


There are some notes on playing nice with others (don't break the 
build) and hooking a community module into maven here 
http://docs.geoserver.org/latest/en/developer/policies/community-modules.html. 
Community modules an optional profile initially, and are only included 
with the build/release when subject to QA/IP review.

--
Jody


--
Jody Garnett

On 13 February 2015 at 10:19, Jim Hughes jn...@ccri.com 
mailto:jn...@ccri.com wrote:


Hi all,

I'm seeking approval to submit a GeoServer community module supporting
GeoMesa's datastore (http://www.geomesa.org/). The purpose is to
provide some additional data about the Hadoop ecosystem to the
GeoServer
user.  Concretely, some of this would let users see the size of their
GeoMesa tables and visualize ingest rates, etc.

Thanks,

Jim


--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot
Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and
more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
mailto:Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel




--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] GSOC 2015?

[Jim Hughes]

I've been mentoring GeoMesa projects this year with Facebook's Open 
Academy.  The spin-up for the full cloud stack is a quite a bit. I've 
been thinking that I might like to identify smaller GeoTools and/or 
GeoServer tasks for students to team up on during the semester long efforts.


Crossing threads, that may give a way to put some effort behind my 'warm 
and fuzzy' feelings for concurrent rendering code.


Just to be clear, I'm not volunteering for GSOC, but rather suggesting a 
way that we could be involved in the future.


Cheers,

Jim

On 02/18/2015 12:07 AM, Andrea Aime wrote:


Historically we have not done so well due to lack of volunteers for 
mentoring.  I guess the professional life of the average geoserver 
developer is just too busy (I've certainly tried and failed...  Twice)


Cheers
Andrea

Il 17/feb/2015 21:11 Jonathan Moules j.mou...@hrwallingford.com 
mailto:j.mou...@hrwallingford.com ha scritto:


Hi List,
It's probably a bit late now (closing date for ideas is 18th Feb I
believe), but does GeoServer do anything with the Google Summer of
Code? I can see a blog post from 2009, but not seen any mention
this year, nor does it appear to have come up at the GT/GS meeting.

Cheers,
Jonathan



HR Wallingford and its subsidiaries uses faxes and emails for
confidential and legally privileged business communications. They
do not of themselves create legal commitments. Disclosure to
parties other than addressees requires our specific consent. We
are not liable for unauthorised disclosures nor reliance upon them.
If you have received this message in error please advise us
immediately and destroy all copies of it.

HR Wallingford Limited
Howbery Park, Wallingford, Oxfordshire, OX10 8BA, United Kingdom
Registered in England No. 02562099




--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and
Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration
 more
Get technology previously reserved for billion-dollar
corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
mailto:Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel



--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk


___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] GeoMesa community module

[Jim Hughes]

Hi all,

I'm seeking approval to submit a GeoServer community module supporting 
GeoMesa's datastore (http://www.geomesa.org/).  The purpose is to 
provide some additional data about the Hadoop ecosystem to the GeoServer 
user.  Concretely, some of this would let users see the size of their 
GeoMesa tables and visualize ingest rates, etc.

Thanks,

Jim

--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] Language Question

[Jim Hughes]

Hi all,

I'm potentially interested in contributing a module to support GeoServer 
integration with GeoMesa.  The existing code is written in Scala, and it 
is by far my preferred language.  Is GeoServer fine with adding other 
JVM languages?

 From a Maven view, the Scala compiler would only be needed while 
building the sub-project housing the Scala code.

Thanks in advance,

Jim

--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Language Question

[Jim Hughes]

Jody,

Ah, wonderful.  It didn't come up in the GitHub language stats, so I was 
worried (needlessly).


Thanks,

Jim

On 01/09/2015 04:44 PM, Jody Garnett wrote:
We have added scala dependencies in the past both for GeoScript - 
which enables the use of scripting languages.and for the css plugin 
which was written in scala. So this would not be the first time...



--
Jody Garnett

On 9 January 2015 at 13:40, Jim Hughes jn...@ccri.com 
mailto:jn...@ccri.com wrote:


Hi all,

I'm potentially interested in contributing a module to support
GeoServer
integration with GeoMesa.  The existing code is written in Scala,
and it
is by far my preferred language.  Is GeoServer fine with adding other
JVM languages?

 From a Maven view, the Scala compiler would only be needed while
building the sub-project housing the Scala code.

Thanks in advance,

Jim


--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot
Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and
more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
mailto:Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel




--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel