Hi Xavier, On Fri, Jun 19, 2015 at 4:23 AM, FRANCISCO XAVIER SUMBA TORAL < [email protected]> wrote: > > > It'd be great if you could point us the fork at github. Then I can > closely > > follow the development, checking the commits, giving feedback on the > > patches, etc. > > I’ve created a new branch from develop and I add you as a contributor [1]. > There is 10 functions implemented.
Perfect, thanks. I've just pointed it from our wiki. The ongoing patch could be found at https://github.com/apache/marmotta/compare/develop...cuent:MARMOTTA-584 I'll try to follow the development from there. BTW, where are you writing the documentation we discussed earlier in the project? As I said, I'd prefer our wiki; although markdown in your code would be better than loosing such knowledge. > My account of GitHub is from another email of Hotmail, is that a problem? Not really. >> I worked with the implementation of NativeFunction. But here appeared a > >> new problem. Some of the RDF files with GeoSPARQL model, not loaded to > >> marmotta. > >> > >> ERROR: "Caused by: org.postgresql.util.PSQLException: ERROR: The string > is > >> too larg > >> to to tsvector (1177006 bytes, m├íximo 1048575 bytes) " > >> > >> As I can solve this problem?. > >> > >> Some geometries (Multipolygons, MultiLineString) have large WKT > > > > Looks that module has some limitations, but I can only found old > references > > related with the issue, such as: > > > > http://requesttracker.wikia.com/wiki/PostgreSQLFullText > > > http://www.postgresql.org/message-id/[email protected] > > > > What version of PostgreSQL are you using? > > I keep having the same issue. I’m using the version 9.4, > Then it's a serious issue. I found the current limitations at: http://www.postgresql.org/docs/9.4/static/textsearch-limitations.html Going into more detail, a text search vector is an array of distinct lexemes (less any stopwords) and their positions. It looks like the tsvector data consumes 2x the space required by the input text, but I think it actually depends on your concrete configuration and input data. Why do we need to store the geometries in a vector? I guess we're not gonna perform full-text search over them, right? Therefore we may need to change how those concrete literals are stored in KiWi. Good progress! Please, continue working and discussing here. Cheers, -- Sergio Fernández Partner Technology Manager Redlink GmbH m: +43 6602747925 e: [email protected] w: http://redlink.co
