BaseX-Talk

basex-talk@mailman.uni-konstanz.de

1 participants
5252 discussions

Adding WKT/WKB To Geo Module
by Zachary DeLuca 03 Nov '13

03 Nov '13

Hi All, apologies in advance for the long message, I have many documents that store WKB (base64-encoded) geometry data (going for speed not readability). I want to be able to do queries where I can use the geo predicate functions with the stored WKB geometry and a provided WKT geometry. Example: Sample document structure: <root><geoWKBdata type=xs:base64Binary/></root> Sample query: collection()/root[geo:intersects(*geo:fromWKB*(geoWKBData), * geo:fromWKT*("LINESTRING((0,0),(1,1))")) I have looked at the module code and the only problem is that all methods assume an input of GML. I don't want to just make functions to convert from WKB/WKT to GML on input because I think that would be very inefficient (slow). I could just hack something together for my own needs, but I would like some input so that ideally I can produce something good enough to contribute back to the project. Options: 1) Add copies of all methods to accept each possible encoding type (GML, WKB, WKT). I don't like this approach because it doesn't scale well, and I don't even know if it's possible? (Pretty sure you can't overload functions in XPath/XQuery) 2) Leave the Geo module the way it is and add "sister" modules for the additional encoding types. Yuck. 3) The only thing that makes sense, really. Define 3 new functions, *fromGML *, *fromBinary*, and *fromText* and change the signatures of all module functions to just accept Geometry objects. That way you can load your geometry however you want and then pass it to the desired function. I will also modify the functions *asText *and *asBinary *to accept a Geometry object, and add an additional *asGML* so that the many existing functions that already return GML (envelope, boundary, etc.) can instead return Geometry, and can then be converted as needed to the desired format. This should scale well too because if any future encoding formats are desired all you need to do is add *fromXYZ* and *asXYZ *functions. With these functions, you could also string together 2 calls to convert between any of the supported encoding types. Does this make sense? It seems easy enough, am I missing anything? Also, assume for a second that I implement #3. Refer to my sample document/query above. As I understand it, for each document in the collection, the back end will have to parse "LINESTRING((0,0),(1,1))" into a Geometry first in order to compare. Is there any way to make that happen only once for the duration of the query? Is it as easy as this?: let $data = geo:fromText("LINESTRING((0,0),(1,1))"); return collection()/root[geo:intersects(*geo:fromWKB*(geoWKBData), $data) This would work, right? (I'm new to XQuery, sorry) So, am I on the right track with this? Have I overlooked some absurdly simple solution to my problem? I would appreciate any and all input. As I said, I would like to go beyond meeting my own needs and actually get this into the code base. I'll leave you with this snippet taken from the EXPath Geo Module Spec: "The data model envisioned by EXPath Geo module is abstract in the sense that it may be possible for module implementers to support more than one encoding on input. Output data types are specified in GML and XML Schema, where appropriate. All that is necessary is that the input geometry be transformable to the model specified by OGC SF and supported by the EXPath implementation. -SNIP- *Implementations are not limited to GML, KML, nor even XML, on input. It is possible that geometries encoded as “Well Known Text”, GeoJSON, or even “Well Known Binary”, among other possibilities, could be supported by an implementation.*" Thanks, Zach

3 9

xquery and hash:md5
by buzz chopra 03 Nov '13

03 Nov '13

This may be a question better suited for an xquery forum but I'll start here since I'm using basex: Can someone suggest why I'd be getting the same result for the hash call even though the content of $r should be changing? let $reps := fn:collection($coll)/Rep for $r at $lcv in $reps let $hash := xs:hexBinary(hash:md5(fn:string($r))) return <hash i="{$lcv}">{$hash}</hash> }; Please let me know if I should post this elsewhere (and please include where). Thanks in advance for any suggestions. Buzz

2 4

Error message
by Lars Johnsen 31 Oct '13

31 Oct '13

When trying to create a database from a folder of approximately 5000 collections (each containing between 200 and 500 files) the processed stopped after two hours with an error something like this: Line too long for a single database {filename} and {line number}. The file itself looks ok, with a single tag in the referenced position. What is the recommended procedure from here? All the best Lars G Johnsen National Library of Norway

2 1

request:http() and servlet context
by Alexander Ryabov 29 Oct '13

29 Oct '13

Hello guys. Are you going to implement request:http() function from http://exquery.github.io/expath-specs-playground/request-module-1.0-specifi… ? What I need is java's request.getContextPath(). Any workarounds? Thanks for your product, Alexander Ryabov

2 2

Fundamental problems with BaseX 7.7
by Werner Dworaczek 29 Oct '13

29 Oct '13

Hi Christian, after migrating to 7.7 I get the error message "No context item defined to evaluate 'root()'". I get this message every time when I am going to access the root node within any of my xQuery functions. This is bad since many of my functions does do exactly that, which wasn’t a problem yet. Why does the old style does not work any more and is there a comfortable workaround to avoid the need for re-writing all my xQuery code? Of course I could pass the root node as an argument to avoid this kind of error, which could improve flexibility, but it’s a lot of work. For test purposes I do have re-written some stuff to get it working with version 7.7 and when I tried to test it with the basex GUI I get "out of memory" errors and my scripts are aborted - actually all my scripts does obviously not work any more. Why does my stuff works great with BaseX 7.6 and not at all with BaseX 7.7. The upgrade seems to change some very general stuff under the hood and it cannot be reduced to some new functionality and minor signature changes for some xQuery built-in-functions. Is there something special with my stuff? I don’t think so. What I do in principle is the following: I first add an XML file info the DB, then I load and start an import xQuery which analyses the XML file just added and adds nodes into the database (update operations). When the import has finished I delete the XML file added originally. Executing the import xQuery works fine with 7.6 and the memory consumption is fortunately low, but the same script aborts after a few seconds with an "out of memory“ error when using BaseX 7.7 - same basic configuration used. It does not make any difference whether I test all stuff with the GUI or let it run automatically by using the client lib. By the way, I do use the perl client lib. It would be great if you could give me some hints how to proceed with 7.7. I have tried even 7.7.2 with no success. Thanks in advance, Regards, Werner

2 1

Re: [basex-talk] strange behaviour of the BaseXgui-editor
by Rob Stapper 26 Oct '13

26 Oct '13

Hi, An update concerning problem 2 The problem occurs when I change the signature of one or more functions in an imported module. If there are too many functioncalls in my main program triggering an error because of this change in signature of the called function than the errorstatusmessages in the editor window get out of sync. An work around is to split the main program in a small first file and a large second file. After debugging the first file I copy an amount of new code from the second file into the debugged first file and start debugging the new copied code. This is repeated until all code is copied into the first part and the second part is empty. Resumé: It is not the size of the program that triggers the sync-problem with the errorstatusmessage but the amount of errors, which in a large program is higher than in a small program. Hope this helps solving the problem. Regards, Rob Stapper Van: Rob Stapper [mailto:r.stapper@lijbrandt.nl] Verzonden: zaterdag 26 oktober 2013 13:45 Aan: 'basex-talk(a)mailman.uni-konstanz.de' Onderwerp: strange behaviour of the BaseXgui-editor Hi, I encountered a few (3) problems with the BasexGui-editor. I use the 7.8 beta release but the issues also occur in previous versions. Problem 1: this is a minor problem but maybe related to problem 2 which is ( for me) a major problem: If I open two ( small) packages of which one has no errors and one has errors then the errorstatus-message at the bottom of the editor doesnt synchronize correctly when switching files. If I switch from the incorrect packagefile to the correct packagefile the errormessage doesnt refresh to ok until I edit this file. Even after closing an activated incorrect packagefile the errormessage stays active. Clicking on the message even reopens the incorrect packagefile. Switching the focus from the correct packagefile to the incorrect packagefile however, doesnt show this behavior. In that case the errorstatus-message changes to the appropriate errormessage of the incorrect file. Problem 2: which is a major problem when working with big files ( 80 kB) I found that when editing a large(r) packagefile the Basexgui-editor doesnt recognize errors that occur after a certain point in the file. If errors occur after this point the errorstatus-message shows ok but I know that the file contains errors and if I try to install the file as a package I get an window with the message below. If the error occurs before that certain point then I get an correct errormessage. However if I delete the code which contains the error the error-message remains. Clicking on the message brings the cursor to the point where the deleted code with the error used to be, even after saving and closing the file. Errormessage ============================================================================ ============================================== Improper use? Potential bug? Your feedback is welcome: Contact: basex-talk(a)mailman.uni-konstanz.de Version: BaseX 7.8 beta Java: Oracle Corporation, 1.7.0_45 OS: Windows Vista, x86 Stack Trace: java.lang.NullPointerException at org.basex.query.func.StaticFuncs.check(StaticFuncs.java:121) at org.basex.query.QueryParser.finish(QueryParser.java:312) at org.basex.query.QueryParser.parseLibrary(QueryParser.java:253) at org.basex.query.QueryContext.parseLibrary(QueryContext.java:197) at org.basex.query.util.pkg.RepoManager.installXQ(RepoManager.java:230) at org.basex.query.util.pkg.RepoManager.install(RepoManager.java:70) at org.basex.core.cmd.RepoInstall.run(RepoInstall.java:37) at org.basex.core.Command.run(Command.java:344) at org.basex.core.Command.exec(Command.java:320) at org.basex.core.Command.execute(Command.java:77) at org.basex.core.Command.execute(Command.java:89) at org.basex.gui.dialog.DialogProgress$1.run(DialogProgress.java:178) ============================================================================ ============================================== Being a responsible Basex-user I does what it says and give you some feedback J Problem 3: This is an old issue that I addressed e few months ago but which you could not reproduce. I found a new clue which might help you solving this issue. The issue was when working in fullscreen mode (F11) in the BasexGUI and then saving a file with save as The save-messagebox gets the focus but disappears behind fullscreen basexgui-window. This has something to do with using a dual monitorsystem. On a single monitor system it works ok: The save-box is placed on top of the fullscreen Basexgui-window and gets the focus. On a dualmonitorsystem the save-box is placed behind the fullscreen Basexgui-window and gets the focus. I hope this insight helps you tackle this minor issue. Well, thats all folk. I hope you can solve the editor-problem soon because I have a really hard time debugging my (large(r)) programs. Regards, Rob Stapper

1 0

parse-xml removes CDATA in text content
by Erdal Karaca 25 Oct '13

25 Oct '13

Hi all, When using parse-xml(-fragment), wrapping CDATA sections are removed and the text content within the original CDATA is returned. For example: parse-xml-fragment("<newNode><data><![CDATA[{cdata}]]></data></newNode>") returns <newNode> <data>{cdata}</data> </newNode> But I need this: <newNode> <data><![CDATA[{cdata}]]></data> </newNode> Do I miss something? Thanks!

3 6

Full Text Module - ft:search function
by John Best 25 Oct '13

25 Oct '13

Dear Christian, The syntax of the ft:search is - *ft:search($db as xs:string, $terms as item()*, $options as item()) as text()** In the $options part, I have seen various options like - Any Word, All Words, Phrase (for Exact Phrase), fuzzy and wildcards. These are really very good features. I am using them extensively. But one thing, I think, is missing and that is the Window/Distance Options for proximity search. Can these options be implemented.. ?? -- Have a nice day JBest

3 5

Re: [basex-talk] suppressing pre-evaluating information in evaluate-chapter in query-info window of BaseX-GUI
by Christian Grün 25 Oct '13

25 Oct '13

Hi Rob, looking forward to your demo (..so this only occur when you are running a large code base?), Christian 2013/10/25 Rob Stapper <r.stapper(a)lijbrandt.nl>: > Hi Christian, > > 1) I just downloaded the latest 7.8 beta release and this issue also occurs > in this version. > 2) The issue also occurs even if I don't interrupt the program. > 3) I'll see if I can reproduce this issue in a demo-program which I'll send > you later. The program where this occurs is about 200 kB including modules. > Maybe this is why the issue occurs. > > Btw. I do like the map:serialize instruction in 7.8 version. I sure helps my > debugging this 200kB monster. However a good debugger would help much more > ;-)) ( sorry, old cow but I couldn't resist ) > > Regards, > Rob > > -----Oorspronkelijk bericht----- > Van: Christian Grün [mailto:christian.gruen@gmail.com] > Verzonden: vrijdag 25 oktober 2013 10:53 > Aan: Rob Stapper > CC: BaseX > Onderwerp: Re: [basex-talk] suppressing pre-evaluating information in > evaluate-chapter in query-info window of BaseX-GUI > > Hi Rob, > >> When using a trace-instruction, like this: let $dum := trace( >> $local:programName, 'programmaNaam: '), in a Xquery program in the >> BaseX-GUI >> >> I get pre-evaluating information of some functions mixed with my trace >> output in the Query-Info-window, see below. > > The Info View will always return both the evaluation and compilation info. > However, the output should be clearly separated: > _________________________________ > > Interrupted. > Evaluating: > - programmaNaam: D03084 > > Compiling: > - pre-evaluating function($911 as element(when)) as map(*) { ... > _________________________________ > > Did the mixup occur with the latest version or snapshot? And does the > problem also occur when you don’t interrupt the query. And my last > question: could you provide us with a little sample query that demonstrates > the issue (you can use prof:sleep(...) to delay the output)? > > Thanks, > Christian > > > >> To be able to follow the programflow, I only want to see my >> trace-output, in this case the programName. >> >> Can I suppress this extra pre-evaluating query info? >> >> >> >> This for your reply in advance. >> >> >> >> Kind regards , >> >> Rob Stapper >> >> ====================================================================== >> ====================================================================== >> == >> >> QUERY INFO WINDOW >> >> Error: >> >> Interrupted. >> >> Evaluating: >> >> - programmaNaam: D03084 >> >> - pre-evaluating function($911 as element(when)) as map(*) { >> function($evaluateStatement.valuedBranche as element(when)) as map(*) >> { >> cobol:selection.valuedBranche.constructor(db:node-id($evaluateStatemen >> t.valuedBranche), >> koopa:evaluateStatement.object.Value($evaluateStatement.valuedBranche) >> , >> $nestedStatements.processor($evaluateStatement.valuedBranche/nestedSta >> tements)) >> }($911) } >> >> - pre-evaluating function($912 as element(when)) as map(*) { >> function($evaluateStatement.valuedBranche as element(when)) as map(*) >> { >> cobol:selection.valuedBranche.constructor(db:node-id($evaluateStatemen >> t.valuedBranche), >> koopa:evaluateStatement.object.Value($evaluateStatement.valuedBranche) >> , >> $nestedStatements.processor($evaluateStatement.valuedBranche/nestedSta >> tements)) >> }($912) } >> >> - pre-evaluating function($913 as element(when)) as map(*) { >> function($evaluateStatement.valuedBranche as element(when)) as map(*) >> { >> cobol:selection.valuedBranche.constructor(db:node-id($evaluateStatemen >> t.valuedBranche), >> koopa:evaluateStatement.object.Value($evaluateStatement.valuedBranche) >> , >> $nestedStatements >> >> >> >> >> _______________________________________________ >> BaseX-Talk mailing list >> BaseX-Talk(a)mailman.uni-konstanz.de >> https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk >> >

1 0

suppressing pre-evaluating information in evaluate-chapter in query-info window of BaseX-GUI
by Rob Stapper 25 Oct '13

25 Oct '13

Hello, When using a trace-instruction, like this: let $dum := trace( $local:programName, 'programmaNaam: '), in a Xquery program in the BaseX-GUI I get pre-evaluating information of some functions mixed with my trace output in the Query-Info-window, see below. To be able to follow the programflow, I only want to see my trace-output, in this case the programName. Can I suppress this extra pre-evaluating query info? This for your reply in advance. Kind regards , Rob Stapper ============================================================================ ================================================================== QUERY INFO WINDOW Error: Interrupted. Evaluating: - programmaNaam: D03084 - pre-evaluating function($911 as element(when)) as map(*) { function($evaluateStatement.valuedBranche as element(when)) as map(*) { cobol:selection.valuedBranche.constructor(db:node-id($evaluateStatement.valu edBranche), koopa:evaluateStatement.object.Value($evaluateStatement.valuedBranche), $nestedStatements.processor($evaluateStatement.valuedBranche/nestedStatement s)) }($911) } - pre-evaluating function($912 as element(when)) as map(*) { function($evaluateStatement.valuedBranche as element(when)) as map(*) { cobol:selection.valuedBranche.constructor(db:node-id($evaluateStatement.valu edBranche), koopa:evaluateStatement.object.Value($evaluateStatement.valuedBranche), $nestedStatements.processor($evaluateStatement.valuedBranche/nestedStatement s)) }($912) } - pre-evaluating function($913 as element(when)) as map(*) { function($evaluateStatement.valuedBranche as element(when)) as map(*) { cobol:selection.valuedBranche.constructor(db:node-id($evaluateStatement.valu edBranche), koopa:evaluateStatement.object.Value($evaluateStatement.valuedBranche), $nestedStatements

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

BaseX-Talk