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
