I also would like to see a file based index while you are at it and not just the in memory spatial lucene engine example.
On Mon, Jul 29, 2013 at 10:44 AM, Andy Seaborne <[email protected]> wrote: > On 27/07/13 14:40, Ying Jiang wrote: > >> Hi, >> >> The default distance units measurement is "miles". I've just committed a >> major change of the codes, including the following updates: >> >> 1) Support spatial indexing of WKT literal, including Point, Polygon or >> any >> other kinds of shapes. >> 2) New property functions of "withinCirle", "withinBox", "intersectsBox", >> "north", "south", "east", "west" >> 3) Support different distance units for "nearby", such as "miles", >> "kilometers", "degrees", "meters" and so on. >> 4) Examples are updated [1]. You can play with the new features of >> jena-spatial. >> >> It's almost half-way of the GSoC project. In the upcoming second half, >> I'll >> bring more visibility of code progress to the community, at least >> one report per week. Thanks to Andy for pointing it out! >> >> [1] >> https://jena-spatial.**googlecode.com/svn/trunk/src/**main/java/examples/ >> **JenaSpatialExample1.java<https://jena-spatial.googlecode.com/svn/trunk/src/main/java/examples/JenaSpatialExample1.java> >> >> >> On Tue, Jul 23, 2013 at 9:37 PM, Andy Seaborne <[email protected]> wrote: >> >> In the example query there is: >>> >>> ?s spatial:nearby (51.3000 -2.71000 100) >>> >>> What units are the "100"? >>> Can the application provide different units? >>> >>> Andy >>> >>> >> > Things are looking very good. > > How does this fit with the original plan in terms of functionality > available? > > > As we enter the second part of the GSoC, we need to be thinking about > > * A release > > That does not mean it's complete and a release needn't be a major cost in > time. Having even one or two people try it out really helps in > understanding what people might do with spatial indexing. > > It can be a message to the users Jena mailing list announcing status of > the project and assuming interested people will grab the source and compile > a jar for themselves. > > But, if you want to, we can do something more packaged - anything up to > and including migrating the code to Jena SVN and putting in a Jenkins job > to build it into Jena's snapshot maven repository that's doable. > > A couple of things go with that: > > * Testing > > src/java/test is a bit empty :-) > > * User documentation > > Enough that someone can setup and use the project - short, to the point > and "now" is better than long and detailed and "later". (The final phase > of GSoC is write-up - that's needs to cover the next developers to come > along.) > > What do you think about this? > > Andy > > -- --- Marco Neumann KONA
