Re: [Geotools-devel] Solr heatmap as a grid coverage

[Justin Deoliveira]

Thanks for the info Jim. Indeed that was my first inclination as well but
once I thought about it I started to struggle with how I could fit it into
the vector pipeline cleanly. HeatmapProcess didn’t seem to really apply
since the aggregation needs to be done on the Solr side and not by the
rendering transform. Is that how the GeoMesa heatmaps work?

To make that approach I would need to hack the request to include all the
required facet parameters. I couldn’t really think of a clean way to do
that although thinking about it again I could probably just throw a bunch
of hints into the query that would trigger the Solr datastore to engage all
of the facetting stuff… I think i’ll explore that approach as well, thanks
Jim!

My other thought was that the heatmap coverage could be useful for reasons
other than purely visualizing areas of density. Like for instance using it
as a mask against another coverage to do some processing… I don’t have a
concrete use case there but thought it had potential.


On Wed, Apr 6, 2016 at 2:14 PM Jim Hughes  wrote:

> Hi Justin,
>
> Since it is somewhat similar, I wanted to share how GeoMesa creates
> heatmaps using GeoServer.  We have a small WPS which riffs on the
> HeatMapProcess (1).  That process is called via an SLD.  By doing that, we
> can have a regular vector layer, but then generate heatmaps for it without
> fiddling with a second coverage, etc.
>
> Potentially, an approach like that could line up more of the rendering
> pipeline to achieve blur, etc.
>
> Cheers,
>
> Jim
>
> 1.
> https://github.com/geotools/geotools/blob/master/modules/unsupported/process-feature/src/main/java/org/geotools/process/vector/HeatmapProcess.java
>
>
> On 04/06/2016 04:02 PM, Justin Deoliveira wrote:
>
> Hi folks,
>
> I’m working on a project to expose Solr’s heatmap capability through
> GeoServer. You can find details about Solr heatmaps here:
>
> https://cwiki.apache.org/confluence/display/solr/Spatial+Search (search
> for “Heatmap Faceting”.
>
> But the gist of it is this: If you have a spatial field that uses the
> recursive prefix tree type (ie. geohash) for indexing then it’s easy using
> Solr’s facetting infrastructure to generate a heatmap grid. What you get
> back from Solr is a 2D array representing the geohash grid, where each
> value is a count of documents that intersect that grid cell. Applying some
> symbolization you can get something that looks like this:
>
>
> https://raw.githubusercontent.com/voyagersearch/leaflet-solr-heatmap/master/sample.png
>
> The above screen shot comes from a leaflet plugin that visualizes the
> heatmap directly in the browser. I would like to add a similar looking
> visualization for GeoTools/GeoServer.
>
> My first thought was to expose this as a new type of coverage reader,
> since the data is simple grid it falls into the model quite easily. The
> major benefit of this approach is that becomes trivial to configure in
> GeoServer and easy to style using all of the existing raster symbology
> support. I’m interested to hear if others think this is a good approach.
>
> If that sounds good my plan was to add this to the existing solr module.
> It won’t add any new dependencies aside from a dependency on the coverage
> module.
>
> @Andrea: you’re listed as the module maintainer… although if I recall
> correctly we agreed to co-maintain the module?
>
> I have a prototype working so if that all sounds good I’ll push up a
> branch for folks to look at. One thing I am particular eager to get some
> feed back on is how to best achieve the blur affect that makes heatmaps
> look “
> pretty”. At the moment what I have done is baked in a parameter to the
> coverage format that specifies a blur radius and then when reading the
> coverage I run it through the Convolve operation to achieve the desired
> affect. It would be ideal if this could be done at symbolization time. I’m
> wondering if we currently have any way to define a blur or some similar
> effect at rendering time with sld? Would a rendering transform work?
>
> Thanks folks.
>
> -Justin
>
>
>
> --
>
>
>
> ___
> GeoTools-Devel mailing 
> listGeoTools-Devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
>
> --
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Boundless YSLD to GeoTools?

[Justin Deoliveira]

Can we enable it in the default profile? Tests all pass for me locally and
the module builds pretty fast. Are there are any other requirements for it
to be in the default unsupported profile?

On Wed, Apr 6, 2016 at 12:31 PM Jody Garnett  wrote:

> It is a community module, so not included in a build profile yet. Please
> download source and build locally!
>
> --
> Jody Garnett
>
> On 6 April 2016 at 10:49, jerickson  wrote:
>
>> Hi all!
>>
>> I am super excited to see ysld added to geotools.  I plan on adding it to
>> geoscript asap.  I can't seem to find it in any maven repo though.  I
>> don't
>> see it in the snapshot repo:
>>
>> https://repo.boundlessgeo.com/snapshot/org/geotools/
>>
>> Thanks,
>> Jared
>>
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://osgeo-org.1560.x6.nabble.com/Boundless-YSLD-to-GeoTools-tp5259070p5259995.html
>> Sent from the geotools-devel mailing list archive at Nabble.com.
>>
>>
>> --
>> ___
>> GeoTools-Devel mailing list
>> GeoTools-Devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
>
>
> --
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] any changes to jai-tools we should know about?

[Jody Garnett]

Catching up on the user list - it seems some jai-tools jars are missing in
action (since geotools 14).

Gabriella Turek reports jt-utilities and jt-iterators - checking online I
can find:

https://repo.boundlessgeo.com/main/org/jaitools/

Last built in august.
--
Jody Garnett
--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] any changes to jai-tools we should know about?

[Jody Garnett]

Looks like Daniele answer this one:

1.0.8 is available too. The wiki page was pointing to the wrong folder. I
> have updated it.
> https://github.com/geosolutions-it/jai-ext/wiki#releases
> http://demo.geo-solutions.it/share/github/jai-ext/releases/1.0.X/1.0.8/
> Hope this helps.


Is there any change we need to make to the geotools release configuration
so that this content is correctly gathered up during the release process? I
have been testing the source code download for geotools, but not the binary
download.

--
Jody Garnett

On 6 April 2016 at 12:08, Jody Garnett  wrote:

> Catching up on the user list - it seems some jai-tools jars are missing in
> action (since geotools 14).
>
> Gabriella Turek reports jt-utilities and jt-iterators - checking online I
> can find:
>
> https://repo.boundlessgeo.com/main/org/jaitools/
>
> Last built in august.
> --
> Jody Garnett
>
--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Boundless YSLD to GeoTools?

[Jody Garnett]

It is a community module, so not included in a build profile yet. Please
download source and build locally!

--
Jody Garnett

On 6 April 2016 at 10:49, jerickson  wrote:

> Hi all!
>
> I am super excited to see ysld added to geotools.  I plan on adding it to
> geoscript asap.  I can't seem to find it in any maven repo though.  I don't
> see it in the snapshot repo:
>
> https://repo.boundlessgeo.com/snapshot/org/geotools/
>
> Thanks,
> Jared
>
>
>
>
>
> --
> View this message in context:
> http://osgeo-org.1560.x6.nabble.com/Boundless-YSLD-to-GeoTools-tp5259070p5259995.html
> Sent from the geotools-devel mailing list archive at Nabble.com.
>
>
> --
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Boundless YSLD to GeoTools?

[jerickson]

Hi all!

I am super excited to see ysld added to geotools.  I plan on adding it to
geoscript asap.  I can't seem to find it in any maven repo though.  I don't
see it in the snapshot repo:

https://repo.boundlessgeo.com/snapshot/org/geotools/

Thanks,
Jared





--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Boundless-YSLD-to-GeoTools-tp5259070p5259995.html
Sent from the geotools-devel mailing list archive at Nabble.com.

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

[Geotools-devel] [JIRA] (GEOT-5401) FastBBOX should not cast to SimpleFeature

[Jes Wulfsberg Nielsen (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Jes Wulfsberg Nielsen created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoTools /  GEOT-5401  
 
 
  FastBBOX should not cast to SimpleFeature   
 

  
 
 
 
 

 
Issue Type: 
  Improvement  
 
 
Affects Versions: 
 14.3  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 render  
 
 
Created: 
 06/Apr/16 11:05 AM  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Jes Wulfsberg Nielsen  
 

  
 
 
 
 

 
 The FastBBOX evaluate method casts the given object to SimpleFeature. This prevents the use of PropertyAccessors for other types of objects. As far as I can see, the cast is actually irrelevant, since the method goes on to use generic property evaluation to access the field (For background, I have a complex, linear-reference-based data set which is not represented as SimpleFeatures, but use CQL/filters through a custom PropertyAccessor. To visualize these, I turn them into SimpleFeatures once all processing is done, and hand them off through a DataStore for a GeoServer to render. I would like to include any filters from the GeoServer query in my processing, but GeoServer hands off a filter which uses FastBBOX, making it unusable against the "raw" objects due to the hardcoded cast, despite the objects containing all relevant information available through the PropertyAccessor.)  
 

  
 
 
 
 

 
 
 

 

Re: [Geotools-devel] ImageMosaic API refactor proposal

[Niels Charlier]

Hello Devon,

Directory walking is part of the harvesting process, which is at the 
moment implemented inside the ImageMosaicReader (see the inner class 
HarvestedResource).
In the API, there is a separate MosaicHarvester interface, as well as a 
very light ImageMosaicReader with all the logic inside the ImageMosaic 
class.
With this API, we can either do one of these two thing to customise 
harvesting:
1. Write our own reader and use all the mosaic functionality through the 
ImageMosaic class.
2. Write our own implementation of MosaicHarvester for a customised 
harvesting process and plug it into the ImageMosaicReader.


Does that make any sense?

Kind Regards
Niels

On 06-04-16 01:48, Devon Tucker wrote:
For my own part, Niels maybe you could throw in some small examples of 
how these API changes would be used in practice to accomplish some of 
the items in the description? For example, how could I customize the 
directory walking with the new API?


Thanks,
Devon

On Tue, Apr 5, 2016 at 4:44 PM, Devon Tucker > wrote:


Hi all,

Just noticed that there wasn't a dedicated email thread for this
proposal and figured I'd kick one off since I've also been
involved in it.


https://github.com/geotools/geotools/wiki/Refactor-ImageMosaic-for-extensibility

I think the description gives a pretty good rationale for what we
want to accomplish with this proposal and I'd like to solicit any
discussion, advice, feedback, etc. from everyone.

Cheers,
Devon




--


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


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