mmit 45a2a1243f.
Github:
[45a2a12|https://github.com/apache/jena/commit/45a2a1243f487d2d1b9f2d65edd04e3316db6e04]
Gitbox: https://gitbox.apache.org/repos/asf?p=jena.git;h=45a2a12
> Remove jena-spatial from the build
> --
>
> Key: JENA-1718
>
mmit e7518f0310308a53d46b3724552ca691dd4b2476 in jena's branch
refs/heads/main from Andy Seaborne
[ https://gitbox.apache.org/repos/asf?p=jena.git;h=e7518f0 ]
Merge pull request #958 from afs/retire-spatial-code
JENA-1718: Retire jena-spatial code
> Remove jena-spatial fr
mmit 45a2a1243f487d2d1b9f2d65edd04e3316db6e04 in jena's branch
refs/heads/main from Andy Seaborne
[ https://gitbox.apache.org/repos/asf?p=jena.git;h=45a2a12 ]
JENA-1718: Retire jena-spatial code
> Remove jena-spatial from the build
> --
>
>
[
https://issues.apache.org/jira/browse/JENA-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Seaborne resolved JENA-1718.
-
Resolution: Fixed
> Remove jena-spatial from the bu
mmit 0d79a3f84f150e131c0d55789d13191e6a7db822 in jena's branch
refs/heads/master from Andy Seaborne
[ https://gitbox.apache.org/repos/asf?p=jena.git;h=0d79a3f ]
JENA-1718: Remove jena-spatial from the build
> Remove jena-spatial from the build
> --
>
>
mmit d29ae498f452801b6e142dfdc7c92deaa46761a7 in jena's branch
refs/heads/master from Andy Seaborne
[ https://gitbox.apache.org/repos/asf?p=jena.git;h=d29ae49 ]
Merge pull request #575 from afs/no-spatial
JENA-1718: Remove jena-spatial from the build
> Remove jena-spatial fr
afs merged pull request #575: JENA-1718: Remove jena-spatial from the build
URL: https://github.com/apache/jena/pull/575
This is an automated message from the Apache Git Service.
To respond to the message, please log on to
afs opened a new pull request #575: JENA-1718: Remove jena-spatial from the
build
URL: https://github.com/apache/jena/pull/575
This is an automated message from the Apache Git Service.
To respond to the message, please log
Andy Seaborne created JENA-1718:
---
Summary: Remove jena-spatial from the build
Key: JENA-1718
URL: https://issues.apache.org/jira/browse/JENA-1718
Project: Apache Jena
Issue Type: Task
ffects Versions: Jena 3.2.0
>Reporter: Osma Suominen
>Assignee: Osma Suominen
> Fix For: Jena 3.3.0
>
>
> As discussed on the dev list, I propose dropping Solr support from jena-text
> and jena-spatial. Reasons:
> # It is not evident how to run it
sers.
> Drop Solr support from jena-text and jena-spatial
> -
>
> Key: JENA-1301
> URL: https://issues.apache.org/jira/browse/JENA-1301
> Project: Apache Jena
> Issue Type: Wish
&g
6 PM:
---
Snapshots are now built (all committers can have Jenkins control access).
I don't remember any mention by users of jena-spatial other than with Lucene so
making that Lucene-only until someone steps up makes sense to me. Its not
GeoSPARQL.
was (Author: andy.seaborne):
Snapshot
can have Jenkins control access).
I don't remember any mentions jena-spatial other than Lucene so making that
Lucene only until someone steps up makes sense to me.
> Drop Solr support from jena-text and jena-spatial
> -
>
>
Github user rvesse commented on the issue:
https://github.com/apache/jena/pull/219
Thanks for adding the more informative error message, the wording is
extremely clear and should avoid lots of user confusion
---
If your project is set up for it, you can reply to this email and have y
the Elasticsearch
implementation of jena-text (JENA-1305) gets done within the same release
cycle, it would be helpful to replace Solr with ES in the documentation, as
they both address a similar use case (external text index for enterprise
applications etc)
The same goes for [jena-spatial
documenta
t at:
https://github.com/apache/jena/pull/220
> Drop Solr support from jena-text and jena-spatial
> -
>
> Key: JENA-1301
> URL: https://issues.apache.org/jira/browse/JENA-1301
>
mmit 45c0fe7d8d266074df65bf4b3745e7f42b4af5a4 in jena's branch
refs/heads/master from [~osma]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=45c0fe7 ]
JENA-1301: Remove Solr support from jena-text and jena-spatial
> Drop Solr support from jena-text and
Github user osma commented on the issue:
https://github.com/apache/jena/pull/219
Added more informative error messages for both jena-text and jena-spatial,
as suggested by @rvesse .
---
If your project is set up for it, you can reply to this email and have your
reply appear on
Github user osma commented on the issue:
https://github.com/apache/jena/pull/219
@rvesse Good point! I'll see what I can do. I don't think there are many
places where this has to be caught, one or two per module (jena-text and
jena-spatial).
---
If your project is set
Github user rvesse commented on the issue:
https://github.com/apache/jena/pull/219
Is there a logical place where we could catch that specific exception and
provide a more obvious error e.g. Index format is no longer supported, please
rebuild the text index with Jena X.Y.Z or higher
ssue:
https://github.com/apache/jena/pull/220
No objection here.
When done and a snapshot available, it would be good to send email to
users@ to give interested parties notice of the upcoming change.
> Drop Solr support from jena-text and jena-
ssue:
https://github.com/apache/jena/pull/220
I tested this together with PR #219. I couldn't find any problems. I will
merge this within the next 2 days unless anyone objects.
> Drop Solr support from jena-text and
Github user osma commented on the issue:
https://github.com/apache/jena/pull/219
I've tested this briefly.
* Unit tests pass for both jena-text and jena-spatial
* I can create a text index and query it normally
* I can create a spatial index and query it nor
Http Client/
Http Components Core. I can't see why it is happening, though possibly a mix of
old and new style APIs of HttpClient tickles an HttpClient/HttpComponents core
problem.
This JIRA solves that for me!
> Drop Solr support from jena-text and
uest:
https://github.com/apache/jena/pull/220
JENA-1301: Drop Solr support from jena-text and jena-spatial
See [JENA-1301](https://issues.apache.org/jira/browse/JENA-1301) for
rationale.
Note that this is implemented after the Lucene 6 upgrade
([JENA-1250](https://issues.apache
.com/osma/jena/tree/jena-1301-drop-solr
I will open a PR soon.
> Drop Solr support from jena-text and jena-spatial
> -
>
> Key: JENA-1301
> URL: https://issues.apache.org/jira/browse/JENA-1301
>
[
https://issues.apache.org/jira/browse/JENA-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15894415#comment-15894415
]
Osma Suominen commented on JENA-1301:
-----
jena-spatial does have some unit tests for
as apparently being used, but the discussion was about other
issues.
I volunteer to do the actual cleaning up if we get agreement on this.
> Drop Solr support from jena-text and jena-spatial
> -
>
> Key: JENA-130
[
https://issues.apache.org/jira/browse/JENA-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Osma Suominen updated JENA-1301:
Summary: Drop Solr support from jena-text and jena-spatial (was: Drop Solr
support from jena-text
Yes, if you are doing updates to the Lucene index while performing reads at
the same time with the current jena-spatial code, you will eventually run
into an "AlreadyClosedException: this IndexWriter is closed". This will
then leave the indexes in a non-safe state because they will
(Just back from a week's hols and catching up ...)
So Stephen
Do I gather from Jena 848 and your email on 8th? May [1] that UNLESS
we can ensure that only one query is being handled at a time it would
be ... unwise ... to use jena-spatial as it stands [2]?
I understand there would
On 05/08/2015 06:51 PM, Stephen Allen wrote:
Hi Chris,
Responding on dev list for a wider audience if that's OK.
No problem. (When I started writing the email it was more
suited to just-you and I didn't think to readdress it
when I'd finished ...)
Chris
Hi Chris,
Responding on dev list for a wider audience if that's OK.
I looked a bit at jena-spatial, and it has the same issues with
transactions that the TextIndexLucene in jena-text previously had.
Basically it is not managing the transaction boundaries properly.
Additionally, jena-spati
d the entire jena package from scratch. I find
>> that
>> jena-jdbc depends upon jena-spatial 1.0.1-SNAPSHOT but the build doesn't
>> build seem to build it. Any idea how to fix this -- OK, I know I can
>> build
>> jena-spatial by hand but there seems to be somethin
On 27/10/13 18:59, Claude Warren wrote:
I am attempting to build the entire jena package from scratch. I find that
jena-jdbc depends upon jena-spatial 1.0.1-SNAPSHOT but the build doesn't
build seem to build it. Any idea how to fix this -- OK, I know I can build
jena-spatial by hand but
I am attempting to build the entire jena package from scratch. I find that
jena-jdbc depends upon jena-spatial 1.0.1-SNAPSHOT but the build doesn't
build seem to build it. Any idea how to fix this -- OK, I know I can build
jena-spatial by hand but there seems to be something wrong with the
(for the current week)
1. wrap things up
2. prepare and submit final evaluation of GSoC project
We're into the wrap-up period now and things seem fairly wrapped up.
The release of Jena 2.11.0 included jena-spatial, and it's part of the
Fuseki server jar as well. It's now down
ds,
> Ying Jiang
>
>
> On Mon, Sep 2, 2013 at 6:04 PM, Ying Jiang wrote:
>> Hi,
>>
>> (for a weekly report)
>> 1. solr support for jena-spatial
>>
>> (for the current week)
>> 1. migration from google code to jena svn trunk
>> 2. documentation
Andy, Ying,
Sorry for taking so long to respond! I had some errant email filters that I
adjusted.
You are handling the JTS library optional-dependency correctly, yes.
The next version of Spatial4j will have built-in WKT parsing support
(already in-progress) and hopefully not too far off is a pol
ere may be a few more changes to setup as I'm trying to put
all the test logging on a solid foundation. However, I'm discovering
that logging configuration for surefire is not entirely "predictable" :-(
Andy
On Sat, Sep 7, 2013 at 4:57 AM, Andy Seaborne wrote:
, Ying Jiang wrote:
> Hi,
>
> (for a weekly report)
> 1. solr support for jena-spatial
>
> (for the current week)
> 1. migration from google code to jena svn trunk
> 2. documentation in jena website
>
> I've just compared the work so far with the original proje
te:
> Ying,
>
> I've had to make jena-spatial like jena-text - the embedded Solr support has
> to be commented out.
>
> Otherwise, the dependencies mean that the whole of Solr gets included on the
> client side, specifically in Fuseki. We don't have a proper Solr testin
Ying,
I've had to make jena-spatial like jena-text - the embedded Solr support
has to be commented out.
Otherwise, the dependencies mean that the whole of Solr gets included on
the client side, specifically in Fuseki. We don't have a proper Solr
testing environment with a fre
Hi David,
Ying has made good progress with building the spatial extension for Jena.
It's the process issue of dealing with the JTS library that I wanted to
check with you.
We'll have a JTS-free build and document how the user can also include
JTS. Is that best way to handle it?
An
On 04/09/13 17:02, Andy Seaborne wrote:
On 04/09/13 16:21, Ying Jiang wrote:
Hi Andy,
Thanks for pointing out the licence issue.
In order to read geo data in WKT literal format, jena-spatial uses JTS
as a parsing tool. Yes, it's not a required feature if no WKT literals
are in geo data
On 04/09/13 16:21, Ying Jiang wrote:
Hi Andy,
Thanks for pointing out the licence issue.
In order to read geo data in WKT literal format, jena-spatial uses JTS
as a parsing tool. Yes, it's not a required feature if no WKT literals
are in geo data.
I think its' the added shapes tha
Hi Andy,
Thanks for pointing out the licence issue.
In order to read geo data in WKT literal format, jena-spatial uses JTS
as a parsing tool. Yes, it's not a required feature if no WKT literals
are in geo data.
I've refactored the code to resolve the problem. Now jena-spatial can
wo
ic static final SpatialContext ctx = SpatialContext.GEO ;
What capabilities does jena-spatial loose with this restriction?
Andy
Hi,
(for a weekly report)
1. solr support for jena-spatial
(for the current week)
1. migration from google code to jena svn trunk
2. documentation in jena website
I've just compared the work so far with the original project plan.
Here are the list of the project scopes in the plan an
On 26/08/13 06:45, Ying Jiang wrote:
Hi Andy,
Thanks for your help! I can make it now with Fuseki 0.2.8-SNAPSHOT.
(for a weekly report)
1. test assembler with fuseki 0.2.8-snapshot
2. spatial indexing command line tools
(for the current week)
1. solr support for jena-spatial
I'm keepi
Hi Andy,
Thanks for your help! I can make it now with Fuseki 0.2.8-SNAPSHOT.
(for a weekly report)
1. test assembler with fuseki 0.2.8-snapshot
2. spatial indexing command line tools
(for the current week)
1. solr support for jena-spatial
Best regards,
Ying Jiang
On Fri, Aug 23, 2013 at 12
On 22/08/13 05:36, Ying Jiang wrote:
Hi,
I'm testing jena-spatial with fuseki. Could you please tell me how to
integrate jena-spatial into fuseki? I mean to make jena-spatial a module
included in fuseki-server.jar.
I find jena-text documentation says it's already done. But I can&#
Hi,
I'm testing jena-spatial with fuseki. Could you please tell me how to
integrate jena-spatial into fuseki? I mean to make jena-spatial a module
included in fuseki-server.jar.
I find jena-text documentation says it's already done. But I can't see it
in jena-fuseki-0.2.7-distr
Hi,
(for a weekly report)
1. spatial dataset assembler and the tests
2. update the examples and the test files, in accordance with the user
document [1]
(for the current week)
1. test assembler with fuseki
2. spatial indexing command line tools
[1] http://code.google.com/p/jena-spatial/wiki
Hi,
(for a weekly report)
Last week, I completed the user document [1] of jena-spatial and fixed
some bugs posted by Macro. The release of jena-spatial-1.0.0 has been
announced in users and dev lists of jena. I hope more users can try it
out and provide valuable feedback.
(for the current week
Hi,
jena-spatial-1.0.0 is now released at:
http://code.google.com/p/jena-spatial/. It's an extension to Apache Jena
ARQ, which combines SPARQL and simple spatial query. It gives applications
the ability to perform simple spatial searches within SPARQL queries. Lucene
spatial
On 07/08/13 16:08, Marco Neumann wrote:
Very nice Ying Jiang,
thank you for the quick changes, I have run a few quick tests and it look
very good. more tests to come.
This project comes along nicely and I consider to replace our
geosparl.orgimplementation with the new GSoc code. We developed th
I think Ying Jiang has already addressed this by using a tdb model instead
during index creation.
On Fri, Aug 9, 2013 at 4:03 PM, Andy Seaborne wrote:
> On 06/08/13 17:47, Marco Neumann wrote:
>
>> also is it correct that jena-spatial does create a full in-memory model
>> b
On 06/08/13 17:47, Marco Neumann wrote:
also is it correct that jena-spatial does create a full in-memory model
before applying the spatial indexing ?
I don't think there is reason to do so.
After all, to generate a list of points to index, it needs:
SELECT * {
?x geo:lat ?lat .
the following ways:
> 1. Add the support for indexing literals without datatypes, i.e. the
> support for b.) in the previous mails. You can find the demostrations in
> the test [1], and in the example code [2].
> 2. Add a test [3] for a file based TDB Dataset with the spatial index.
&
d TDB Dataset with the spatial index.
Actually, jena-spatial is suitable for any types of Dataset, including
in-memory ones, file based ones (such as TDB), or something else. Please
check "JenaSpatialExample1.joinDataset()" in the example code [2], which
shows how to add the spatial indexin
I would lean towards b.) but that does not mean to omit a.)
On Tue, Aug 6, 2013 at 12:42 PM, Ying Jiang wrote:
> Hi, Marco
>
> The current indexing strategy requires both the followings:
> 1) the predicates to be geo:lat and geo:long;
> 2) the datatypes of objects are: XSDfloat, XSDdecimal, XSD
also is it correct that jena-spatial does create a full in-memory model
before applying the spatial indexing ?
On Tue, Aug 6, 2013 at 12:04 PM, Ying Jiang wrote:
> Hi,
>
> I'm with the dev list. Any problems with your tests?
>
> Best regards,
> Ying Jiang
>
> O
Hi, Marco
The current indexing strategy requires both the followings:
1) the predicates to be geo:lat and geo:long;
2) the datatypes of objects are: XSDfloat, XSDdecimal, XSDdouble, XSDinteger
For b) you mentioned. Jena will regard no datatypes of the objects.
Shall we remove the requirements of
the current project requires the spatial data for points to come typed as
xsd:float. otherwise data is ignored during indexing.
example:
a.) {will be indexed}
airports:EGBB rdf:type airports_sc:LargeAirport ;
geo:lat "52.4539"^^xsd:float ;
geo:long "-1.74803"^^xsd:float ;
rdfs:label "
gt;
>> 1) Release:
>> Firstly, I'd like to make a release in the Google code [1] and announce in
>> the jena user mailing list for the feedbacks, marking it as
>> "jena-spatial-1.0.0". It should include the current source code and a
>> compiled jar. I
Hi,
I'm with the dev list. Any problems with your tests?
Best regards,
Ying Jiang
On Tue, Aug 6, 2013 at 9:58 PM, Marco Neumann wrote:
> Andy,
>
> is Ying Jiang a member of the dev list?
>
> Marco
>
>
>
> On Mon, Aug 5, 2013 at 5:16 PM, Marco Neumann >wrote:
>
> > ok so I have the project now
Andy,
is Ying Jiang a member of the dev list?
Marco
On Mon, Aug 5, 2013 at 5:16 PM, Marco Neumann wrote:
> ok so I have the project now in the correct setup and the code compiles
> fine but with 1677 warnings as mention by you
>
> I am going to test the code with larger rdf data sets in the c
ok so I have the project now in the correct setup and the code compiles
fine but with 1677 warnings as mention by you
I am going to test the code with larger rdf data sets in the coming days.
On Mon, Aug 5, 2013 at 10:16 AM, Andy Seaborne wrote:
> On 05/08/13 14:48, Marco Neumann wrote:
>
>>
On 05/08/13 14:48, Marco Neumann wrote:
On Mon, Aug 5, 2013 at 9:41 AM, Andy Seaborne wrote:
On 05/08/13 14:25, Marco Neumann wrote:
Andy,
yes, but I am discussing some details with Ying Jiang off-list there are
some configuration questions I still have. The code itself looks OK.
Great -
On 03/08/13 11:11, Ying Jiang wrote:
>>>
>>> Hi Andy,
>>>>
>>>> Thanks for the comments! Please check my replies below.
>>>>
>>>> 1) Release:
>>>> Firstly, I'd like to make a release in the Google code [1] and announ
feedbacks, marking it as
"jena-spatial-1.0.0". It should include the current source code and a
compiled jar. I'll also make a tag of "jena-spatial-1.0.0" in Google code
svn. However, during coding, the version of the "jena-parent" is
"7-SNAPSHOT",
with "
y replies below.
>>
>> 1) Release:
>> Firstly, I'd like to make a release in the Google code [1] and announce in
>> the jena user mailing list for the feedbacks, marking it as
>> "jena-spatial-1.0.0". It should include the current source code and a
>&
rking it as
"jena-spatial-1.0.0". It should include the current source code and a
compiled jar. I'll also make a tag of "jena-spatial-1.0.0" in Google code
svn. However, during coding, the version of the "jena-parent" is "7-SNAPSHOT",
with "ver.jena&
>> 2) New property functions of "withinCirle", "withinBox",
> > "intersectsBox",
> > >> "north", "south", "east", "west"
> > >> 3) Support different distance units for "nearby", such as &q
ds of shapes.
> >> 2) New property functions of "withinCirle", "withinBox",
> "intersectsBox",
> >> "north", "south", "east", "west"
> >> 3) Support different distance units for "nearby", such
Hi Andy,
Thanks for the comments! Please check my replies below.
1) Release:
Firstly, I'd like to make a release in the Google code [1] and announce in
the jena user mailing list for the feedbacks, marking it as
"jena-spatial-1.0.0". It should include the current source code and
t;withinCirle", "withinBox", "intersectsBox",
>> "north", "south", "east", "west"
>> 3) Support different distance units for "nearby", such as "miles",
>> "kilometers", "degrees"
2) New property functions of "withinCirle", "withinBox", "intersectsBox",
"north", "south", "east", "west"
3) Support different distance units for "nearby", such as "miles",
"kilometers", "degrees&
inCirle", "withinBox", "intersectsBox",
"north", "south", "east", "west"
3) Support different distance units for "nearby", such as "miles",
"kilometers", "degrees", "meters" and so on.
4) E
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
gc:wktLiteral .
They are widely used in semantic geodata. I think I'm supposed to support
both format in jena-spatial. If you know more formats in other data
sources, please tell me. Thanks!
Following the way of jena-text, I'm working on the project of jena-spatial
in Google Code [1]. No
e the code to be
committed there in the coming months. I'd be grateful to your help
when I ask questions in the dev mailing list.
[1] http://code.google.com/p/jena-spatial/
Best regards,
Ying Jiang
How's it going?
What are the immediately goals for the work?
Andy
e the code to be
committed there in the coming months. I'd be grateful to your help
when I ask questions in the dev mailing list.
[1] http://code.google.com/p/jena-spatial/
Best regards,
Ying Jiang
Hi Ying,
Do you want to put the full project description up on that site? The
GoSC see
e the code to be
committed there in the coming months. I'd be grateful to your help
when I ask questions in the dev mailing list.
[1] http://code.google.com/p/jena-spatial/
Best regards,
Ying Jiang
Hi Ying,
Do you want to put the full project description up on that site? The
GoSC see
e coming months. I'd be grateful to your help
when I ask questions in the dev mailing list.
[1] http://code.google.com/p/jena-spatial/
Best regards,
Ying Jiang
Andy Seaborne wrote:
> > I'm pleased to announce that Ying Jiang has had the jena-spatial project
> [2]
> > accepted into the the Google Summer of Code.
> >
> > Please welcome Ying Jiang [1].
> >
> > Andy
> >
> >
> > [1] Intro. htt
Welcome! I look forward to issuing my first geospatial query!
-Stephen
On Tue, May 28, 2013 at 9:14 AM, Andy Seaborne wrote:
> I'm pleased to announce that Ying Jiang has had the jena-spatial project [2]
> accepted into the the Google Summer of Code.
>
> Please welc
I'm pleased to announce that Ying Jiang has had the jena-spatial project
[2] accepted into the the Google Summer of Code.
Please welcome Ying Jiang [1].
Andy
[1] Intro. http://s.apache.org/cgS
[2] Submitted project description:
Background
GeoSPARQL [1] is a complete approa
89 matches
Mail list logo
