Can anyone give me guidance on how to hook an optimized (indexed) bounding
box feature lookup to
the ContentDataStore/ContentFeatureStore/FeatureReader<SimpleFeatureType,
SimpleFeature> class hierarchy?
i.e. I was assuming there was a getFeaturesByBoundingBox( ... ) type of
function, but that doesn't seem to be available. What is my integration
point here?
On Tue, Nov 22, 2011 at 6:49 PM, Chris Shain <[email protected]> wrote:
> So far I'm in pretty good shape- I can store and retrieve SimpleFeatures,
> and I can see said features on OpenLayers and in ArcMap (via WFS). In the
> end, not too hard to do, once I got all of the dependencies right.
>
> Now on to bboxes...
>
> Bounding boxes, as near as I can tell, work as follows- assume you have a
> 3D coordinate space, X, Y, Z. Z is elevation, and is often 0. You need to
> figure out quickly which Features of a given type intersect a given
> rectangular box (min/max along each dimension, representing what the user
> is currently looking at), keeping in mind that features may be
> non-rectangular and may not have any points inside of the rectangle. For
> example, given the bounding box ((0,0),(10,10)), that box is intersected by
> the triangle (polygon) ((5,12),(12,5),(12,12)) even though none of those
> points fall inside of the box. This is complicated by the fact that the
> bounding box may be small or quite large (e.g. the whole world). From my
> reading, it seems like the way that this is done is first to geohash the
> centroid of any given SimpleFeature, then truncate the geohash to an
> acceptable search range (I am assuming that this derives from the size of
> the bbox?), then calculate the 9 neighbors of that geohash (resulting in a
> 3x3 rectangle of 9 geohashes). That gives you 9 prefixes that you need to
> search on in order to quickly find the features in a bounding box around
> the feature. Is that right?
>
>
> So in my case, I have effectively unlimited storage space (literally
> petabytes) and fixed lookup/sorted scan time. Given that, I could
> generate a row for every possible prefix for any given feature centroid
> geohash I've indexed (e.g. "a", "ab", "abc", abc1", "abc12", "abc123"), and
> in each of those rows, a value for every feature id with that geohash
> prefix (I also have the pleasure of being schemaless). That way given a
> bounding box with a given centroid geohash and precision (again, does
> geohash precision correspond to size of the bounding box?), I can always
> look up in exactly 9 fetches operations everything in that bbox. Does that
> seem right?
>
>
>
>
>
> On Thu, Nov 17, 2011 at 4:26 AM, Andrea Aime <[email protected]
> > wrote:
>
>> On Thu, Nov 17, 2011 at 1:05 AM, Chris Shain <[email protected]> wrote:
>>
>>> FYI the immediate reason that my data source was not showing up was that
>>> I was building against the wrong version of the GeoTools libs (duh). I had
>>> been building against 8.0-M3, but the stable version of GeoServer uses
>>> 2.7.3 it seems.
>>
>>
>> Correct. New developments are always made first against trunk and then
>> backported to the stable series once they are good, that's why I pointed
>> you there.
>> Also, the set of stores based on ContentDataStore on 2.7.x is a lot
>> smaller (basically just the jdbc ones).
>>
>>
>>>
>>> The next question that I have is around packaging. It seems that most
>>> of the other data stores have very minimal additional baggage, but
>>> unfortunately the HBase client carries ~50MB of additional dependencies.
>>> Obviously including all of that in the plugin jar isn't optimal. Is there
>>> an application-level way to instruct GeoServer to append some folder (or
>>> set of jars) to it's classpath? Everything I read suggests that it is the
>>> (WAR'd) application's responsibility (in this case GeoServer) to manage
>>> dependencies, not the application server, which kind of makes sense to me.
>>>
>>
>> GeoServer does not have, at the moment, the ability to pick jars from a
>> random folder. Extensions are zip files containing a set of jars that you
>> unzip and drop in WEB-INF/lib.
>> If someone wants to try and add support for loading external jars it may
>> be good, I guess.
>> The thing is that, regardless, there is no guarantee that an extension
>> built for 2.1.1 will work for 2.1.2 (a datastore will, something that
>> depends on some internal
>> GeoServer class might not), so putting them, say, in the data dir, might
>> cause quite a bit of confusion when people upgrade GeoServer.
>>
>> Cheers
>> Andrea
>>
>> --
>> -------------------------------------------------------
>> Ing. Andrea Aime
>> GeoSolutions S.A.S.
>> Tech lead
>>
>> Via Poggio alle Viti 1187
>> 55054 Massarosa (LU)
>> Italy
>>
>> phone: +39 0584 962313
>> fax: +39 0584 962313
>>
>> http://www.geo-solutions.it
>> http://geo-solutions.blogspot.com/
>> http://www.youtube.com/user/GeoSolutionsIT
>> http://www.linkedin.com/in/andreaaime
>> http://twitter.com/geowolf
>>
>> -------------------------------------------------------
>>
>
>
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
