Re: [sqlite] geopoly_contains_point(P,X,Y) doc is overly modest
oh, I hope you dont do that since the application I am working on hopes to exploit the retval = 4 of geopoly_overlap ! regards, Graham On 02-12-2018 7:52 am, Richard Hipp wrote: On 12/1/18, Larry Brasfield wrote: The documentation at https://www.sqlite.org/geopoly.html , at 3.8. for geopoly_contains_point(), asserts that the function “returns true if and only if the coordinate X,Y is inside or on the boundary of the polygon P.” As now implemented, in the v3.26 release, it returns 1 where the point is on a boundary and 2 where the point is inside of the boundary. The geopoly_overlap() and geopoly_within() routines are similarly modest about what they compute. Geopoly_within(A,B) returns +1 if B is completely contained inside of A, and returns +2 if A and B are the same polygon. Geopoly_overlap(A,B) returns 4 different non-zero values (1, 2, 3, and 4) depending on whether or not A is contained in B (2), B is contained in A (3), A and B are the same polygon (4), or if they just overlap (1). I haven't documented those behaviors, because I wanted to leave myself some wiggle room in case I need to change the behavior in the future. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] function named geopolyCosine is a misnomer
Hi, I was very interested in the numerical approximation used in the function named geopolyCosine and after a bit of on-line research decided to test it's accuracy myself. What I discovered was that the function in fact returns the sin value rather than the cosine value. This is quickly noticed by checking the return value when r = 0. The value returned is 0 rather than the expected 1.0 The function is only employed by the geopoly_regular function which I found does actually return the expected shape (taking into account the approximation being used). On checking the geopoly_regular program code I saw that the coordinate calculation formulae cancel out the incorrect value returned from geopolyCosine by essentially reversing the normal understanding of sin and cosine. I hope it is understood that I do not wish to offend. I would, in fact appreciate a link to the site where this approximation was discovered. regards, Graham ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] bug: error in code for geopoly_ccw function
hi,
In my posting on 20th November I supplied output from the cli buit from
the snapshot that includes the new geopoly function geopoly_ccw.
That output showed incorrect results being returned from an attempt to
reverse the direction of a polygon in CW mode after a mirror transform
of a CCW polygon about the X axis.
There has been no response to that mail, so as I am convinced there is
an error in the program code I decided to resend my report rephrased as
a bug report.
Looking at the code from the sqlite3.c file I can see that the for loop
"for(ii=2, jj=p->nVertex*2 - 4; ii create virtual table newtab using geopoly(a,b,c);
sqlite> insert into newtab (_shape) values
('[[0,0],[88,0],[88,80],[60,80],[30,40],[0,40],[0,0]]');
sqlite> select geopoly_json(_shape) from newtab;
[[0.0,0.0],[88.0,0.0],[88.0,80.0],[60.0,80.0],[30.0,40.0],[0.0,40.0],[0.0,0.0]]
sqlite> select geopoly_json(geopoly_xform(_shape, 1,0,0,-1,0,0)) from
newtab;
[[0.0,0.0],[88.0,0.0],[88.0,-80.0],[60.0,-80.0],[30.0,-40.0],[0.0,-40.0],[0.0,0.0]]
sqlite> select geopoly_json(geopoly_ccw(geopoly_xform(_shape,
1,0,0,-1,0,0))) from newtab;
[[0.0,0.0],[30.0,-40.0],[60.0,-80.0],[88.0,-80.0],[88.0,0.0],[0.0,-40.0],[0.0,0.0]]
The correct output should have been
[[0,0][0,-40][30,-40][60,-80][88,-80][88,0][0,0]]
Please accept my apologies if this matter had already been taken into
consideration. I do understand that the authors are very busy people.
regards,
Graham
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] geopoly - testing the snapshot code gives error in geopoly_ccw
Hi,
thanks for giving access to the snapshot. I paste below output from the
CLI. The pragma compile_options now works, but there is an error in the
coordinates returned from applying geopoly_ccw those produced by a
simple mirror about x axis.
SQLite version 3.26.0 2018-11-17 14:26:45
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> pragma compile_options;
COMPILER=gcc-8.1.0
ENABLE_GEOPOLY
ENABLE_JSON1
ENABLE_RTREE
THREADSAFE=0
sqlite> create virtual table newtab using geopoly(a,b,c);
sqlite> insert into newtab (_shape) values
('[[0,0],[88,0],[88,80],[60,80],[30,40],[0,40],[0,0]]');
sqlite> select geopoly_json(_shape) from newtab;
[[0.0,0.0],[88.0,0.0],[88.0,80.0],[60.0,80.0],[30.0,40.0],[0.0,40.0],[0.0,0.0]]
sqlite> select geopoly_json(geopoly_xform(_shape, 1,0,0,-1,0,0)) from
newtab;
[[0.0,0.0],[88.0,0.0],[88.0,-80.0],[60.0,-80.0],[30.0,-40.0],[0.0,-40.0],[0.0,0.0]]
sqlite> select geopoly_json(geopoly_ccw(geopoly_xform(_shape,
1,0,0,-1,0,0))) from newtab;
[[0.0,0.0],[30.0,-40.0],[60.0,-80.0],[88.0,-80.0],[88.0,0.0],[0.0,-40.0],[0.0,0.0]]
I think my process is Ok.
regards,
Graham
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] geopoly - rules re data entry
Thanks for the clarification and news of the up-coming additions. This issue will not impede me for the moment. Oh, and by the way - the pragma compile_options sql command is still not including geopoly in the return list. (using 3.25.3) Graham On 18-11-2018 3:57 pm, Richard Hipp wrote: On 11/17/18, Richard Damon wrote: On 11/17/18 8:37 PM, Graham Hardman wrote: My question then is, is it really necessary to ensure a counterclockwise order when a polygon shape is entered for the first time in the table. My guess would be that SOME operations will need the vertices in the right order, and others will work regardless of order. Yeah. For example, the geopoly_area() routine returns a negative number if the vertexes rotate iCW instead of CCW (which is also a convenient way to figure out of the order is incorrect). I'm not sure what other routines malfunction, but I suspect most of them will. There is a new routine on trunk (and soon to be in 3.26.0) named geopoly_ccw() that puts the vertexes in the correct CCW order if they are not already so. This routine was added because I discovered that many legacy GeoJSON files do not follow the rules and put polygon vertexes in CW order. I suppose it can also be used after geopoly_xform() to make sure that the vertexes are in the correct order there, too. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] geopoly - rules re data entry
Hi, The documentation for the geopoly module states that the vertices must be defined in a counter-clockwise order so that the interior of the polygon is on the left of the element as it is drawn. However, I have discovered that a polygon transformed with geopoly_xform can result in a polygon having vertices reading clockwise. For instance, a polygon mirrored about either the x or y axis will produce this effect. The geopoly module allows these transformed polygons to be added to the table. If I then create an exact same polygon shape having counterclockwise order for the vertices and use the geopoly_overlap function to test it against the one with clockwise order I find the result = 4, meaning the polygons are regarded as identical. My question then is, is it really necessary to ensure a counterclockwise order when a polygon shape is entered for the first time in the table. regards, Graham ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] curious discovery about geopoly module
Thanks. In my case there is no installer as such. My vba code runs inside the same process as the host cad system. In this case Bricscad has already loaded their copy of dqlite3.dll and my like-named file could not demand precedence. Graham On 02-11-2018 3:16 am, Simon Slavin wrote: On 1 Nov 2018, at 10:40am, R Smith wrote: Most applications play nice and do not install their greasy little DLLs to the Widows DLL common area, but just hug them locally (in the app folder). But some, thinking probably they were doing the right thing, do install DLLs to the common area, and sometimes this includes a DLL like sqlite3.dll which starts causing problems for everyone else using it, because they don't actually distribute/install newest versions, so everything else loading the same library gets the last installed version of the last app to successfully install to the common area. That's the problem. The standard Windows installer has a way of saying "install this common-area DLL if and only if there isn't one in there, or it's a later version than the one already in there". When only professionals wrote Windows programs that needed installing, it was fine, but now days few people use it because (A) Some DLLs have bugs, the programmer figured this out and wrote around the bug, but their work-around does't involve a version-check. Updating the DLL fixes a bug their app depends on. (B) My installer installs my app which works perfectly. If you have trouble with another app, take it up with their support team, not mine. Now days most houses use Installshield which has its own problems. Simon. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] curious discovery about geopoly module
Thanks for the very detailed info. I am certainly a lot wiser now! Graham On 01-11-2018 11:40 pm, R Smith wrote: On 2018/11/01 9:51 AM, Graham Hardman wrote: I am pleased about this, although still puzzled by the fact that the windows LoadLibrary call returned a non null pointer and windows help file implies that it is ok for multiple copies of same name libraries to be loaded together. This is an old Windows problem, one which I think they (M$) have self-regretted so many times. What I deduced long ago after resolving a similar problem (and I could be wrong, I don't have insider info on it) is that Windows' idea of DLLs was to have it so the DLLs live in a common area in the Windows system path (typically c:\program files\common files\system) from where it can be shared to all the lovely apps everywhere needing to use it. AND, how wonderful would it be if, when a DLL is updated, everyone benefits from the new version. Right? So what they did is the DLL loader seems to have a rule of loading the DLL FIRST from the windows common DLL area, and only if not available there (because that's where the updatedest DLL would be, right?) then see if local DLL exists next to the app and loads it. Most applications play nice and do not install their greasy little DLLs to the Widows DLL common area, but just hug them locally (in the app folder). But some, thinking probably they were doing the right thing, do install DLLs to the common area, and sometimes this includes a DLL like sqlite3.dll which starts causing problems for everyone else using it, because they don't actually distribute/install newest versions, so everything else loading the same library gets the last installed version of the last app to successfully install to the common area. Even this wouldn't be such a catastrophe if the common area DLLs weren't usually "in use" by the services it supports, so it can't be updated by anyone else, unless you KNOW which service(s) is/are using it and stop all of them. This leaves a new application install with very few options, if you can't get Windows to use your local DLL, nor can you update the "in-use" one in the common area... How then do you cause the system to use your newest DLL? There are a few hacky ways: 1 - The easiest is to just use a different name (and to do your part by not installing it for all). 2 - Use a side-by-side isolation assembly. See: https://docs.microsoft.com/en-us/windows/desktop/SbsCs/isolated-applications-and-side-by-side-assemblies-portal This option is fine if you develop new software to be isolated from any DLL conflicts from the start, but it's a LOT of effort to just fix one conflict. 3 - This is my favourite - Use DLL redirection, which involves simply adding a .local file to your app path (so myapp.exe must be accompanied by myapp.local). This does require and extra file to maintain, but it's relatively easy and means you don't need to be concerned with sorting out DLL naming or isolation. I believe the file's presence matters, but its content is irrelevant (I usually add a line like "** Force local DLLs **" as the content), which makes Widows look locally first when loading DLLs. See: https://docs.microsoft.com/en-us/windows/desktop/dlls/dynamic-link-library-redirection NB! - The .local file will force local redirection for ALL DLLs you use, some of which may not be intended, like if you supply xxx.dll as a back-up, but would prefer Windows to use it's internal (and possibly newer) xxx.dll if present. NB2! - As is the standard for M$, every fix must have a fallback... so known common DLLs cannot be redirected like this (there is a list maintained in the Windows registry in HKLM/SYSTEM/CurrentControlSet/Control/Session Manager/KnownDLLs/ of what Windows regards as "common" DLLs. Make sure your DLL is not in there, for if it is, options 1 & 2 above are your only remaining venues). HTH - Cheers! Ryan ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] curious discovery about geopoly module
Hi, I have managed to get passed the first hurdle by renaming my custom library and then editing all the statements declaring functions to be imported from my custom library. My code now reports correct version and source_id values, and can create the intended geopoly tables. I am pleased about this, although still puzzled by the fact that the windows LoadLibrary call returned a non null pointer and windows help file implies that it is ok for multiple copies of same name libraries to be loaded together. Also, by checking, I found that my Bricscad application (latest version) contains the exact same older version 3.8.5 that my vba code ended up hooking into. I will discuss this with them, but perhaps the problem arose because vba runs in the same 64-bit process as their application. Thanks to all who responded to my posts. regards, Graham On 01-11-2018 1:03 am, Dominique Devienne wrote: On Wed, Oct 31, 2018 at 12:51 PM Graham Holden wrote: > There are, of course, multiple apps on my system that use sqlite3.dll - including the Bricscad app that I am running my vba code from.Speculating somewhat: Have you tried updating the copy Briscad is using? If one version is already in memory, you _may_ have problems persuading Windows to load a different version, and -- even if you can -- I've a feeling that SQLite might not like that.Graham. From past discussions on this list, I remember that loading SQLite several times in the same process, even with renamed symbols, would be problematic on Posix system, because SQLite uses a "singleton" of some kind (as a workaround for broken POSIX semantic around file IO if I recall correctly). But on Windows, there was no such restriction that I can recall. Dan or Richard can probably shed more light on this. Seems like Graham already has a custom build, so renaming the symbols sounds possible at least. FWIW. --DD ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] curious discovery about geopoly module
Hi, and thanks for the suggestion. I am familiar with the vbRichClient solution. There are also odbc drivers that are free to use but in the end I am looking for system that has to work as 64 bit inside 64-bit Autocad where vba runs in-process. The system that I am using seems ideal in that I can build my custom library to include the geopoly module and that of course doesnt get enabled in the standard releases from the sqlite.org site. See my reply to Richard Hipp's message. Once I overcome the problem and get my custom library loaded I expect to make good progress. regards, Graham On 31-10-2018 12:35 am, Vladimir Vissoultchev wrote: You can try some other sqlite wrapper for VBA, for instance vbRichClient ships with 3.24 -- http://www.vbrichclient.com/#/en/Downloads.htm Unfortunately as it's primary target is VB6 the stdcall port of sqlite is compiled to x86 binary only. cheers, -Original Message- From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On Behalf Of Graham Hardman Sent: Tuesday, October 30, 2018 11:49 AM To: SQLite mailing list Subject: [sqlite] curious discovery about geopoly module Hi everybody, regarding the geopoly module in version 3.25.2 a couple of weeks ago I wrote about the fact that the 'pragma compile_options' command failed to display when I was trying to check that my special build of the sqlite dll library and the command line shell was working corrrectly. Richard Hipp's reply was to announce that he had forgotten to fully broadcast the new module to the rest of the code. Fair enough i thought, since i was still able to test out my ideas using the shell interface and in my SQLiteExpert program on my windows 10 pc. Since my previous message I have been doing some tests in 64-bit vba by adapting code released on github by Govert: SQLiteForExcel [1] It has been performing well except that, to my great surprise I have been unable to get it to create a virtual table using geopoly. Tonight I have documented this in a module that runs some general tests that all succeed (creating normal tables, inserting records, and querying the results. A simple Rtree virtual table was also part of the testing). The final part of my testing was to try to create a geopoly vitual table. The prepared statement succeeded, but the step process failed - returning 1. The extended error code was also 1, and the error message was "no such module: geopoly" I guess that makes sense in one way, but it begs the question of why the shell and my version of SQLiteExpert find a way to understand what is required. In the meantime it seems I shall have to suspend my vba coding until the next release where hopefully the above issue will be fixed. I can provide my code and the library if wished. The last few lines from my debug printing to the vba intermediate window is pasted below: --begin test with a simple geopoly virtual table opening an in memory database SQLite3Open returned 0 open the rtree virtual table sqlcmd is: 'create virtual table newtab using geopoly(a,b,c)' SQLite3PrepareV2 returned 0 SQLite3Step failed returning 1 Extended error code is: 1 Extended error message is: no such module: geopoly SQLite3Finalize returned 1 forced to abandon testing since geopoly table could not be created- assertion documented Regards, Graham Hardman. Links: -- [1] https://github.com/govert/SQLiteForExcel ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] curious discovery about geopoly module
Hi Richard, I have discovered that there is a problem in that the vba code (I got from the github site) is somehow failing to load my custom library from my specified location and in fact keeps referencing a file with version 3.8.5 from 2014. I am not sure how to overcome this right now apart from renaming my custom library to something else apart from sqlite3.dll and updating the references in the sqlite module. The module uses the declare keyword to hook into externally declared functions in another dll, and also adds references to some windows functions - one of which is the LoadLibraryA function from kernel32 and that is the one that is asked to load my library. There are, of course, multiple apps on my system that use sqlite3.dll - including the Bricscad app that I am running my vba code from. Regarding the other questions: My custom shell and library (referenced in sqliteexpert) return the correct string for sqlite_source_id(), and they do know that geopoly is active because I can create the virtual table and use all of the geopoly special functions. I welcome any help you can provide. Graham On 31-10-2018 12:34 am, Richard Hipp wrote: On 10/30/18, Graham Hardman wrote: To clarify: I built my own versions of the library and shell using the latest amalgamation (3.25.2) specifically to test the geopoly Are you certain that the third-party tool is picking up your custom DLL? Verify by looking at the results of "SELECT sqlite_source_id();" Are you certain that you enabled GeoPoly when you built your custom DLL? Remember that GeoPoly is an extension that defaults off. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] curious discovery about geopoly module
To clarify: I built my own versions of the library and shell using the latest amalgamation (3.25.2) specifically to test the geopoly capability. The build process completed successfully with no error code, and as I said allow me to create tables and use the geopoly functionality in the command shell and sqliteexpert. the vba module for 64 bit windows does not need the stdcall library offered on the github site. Thanks, Graham On 31-10-2018 12:13 am, Clemens Ladisch wrote: Graham Hardman wrote: SQLiteForExcel [1] https://github.com/govert/SQLiteForExcel "sqlite3.dll is a copy of SQLite version 3.11.1" "no such module: geopoly" I guess that makes sense in one way, but it begs the question of why the shell and my version of SQLiteExpert find a way to understand what is required. Because they updated their copy of SQLite more recently than three years ago. Regards, Clemens ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] curious discovery about geopoly module
Hi everybody, regarding the geopoly module in version 3.25.2 a couple of weeks ago I wrote about the fact that the 'pragma compile_options' command failed to display when I was trying to check that my special build of the sqlite dll library and the command line shell was working corrrectly. Richard Hipp's reply was to announce that he had forgotten to fully broadcast the new module to the rest of the code. Fair enough i thought, since i was still able to test out my ideas using the shell interface and in my SQLiteExpert program on my windows 10 pc. Since my previous message I have been doing some tests in 64-bit vba by adapting code released on github by Govert: SQLiteForExcel [1] It has been performing well except that, to my great surprise I have been unable to get it to create a virtual table using geopoly. Tonight I have documented this in a module that runs some general tests that all succeed (creating normal tables, inserting records, and querying the results. A simple Rtree virtual table was also part of the testing). The final part of my testing was to try to create a geopoly vitual table. The prepared statement succeeded, but the step process failed - returning 1. The extended error code was also 1, and the error message was "no such module: geopoly" I guess that makes sense in one way, but it begs the question of why the shell and my version of SQLiteExpert find a way to understand what is required. In the meantime it seems I shall have to suspend my vba coding until the next release where hopefully the above issue will be fixed. I can provide my code and the library if wished. The last few lines from my debug printing to the vba intermediate window is pasted below: --begin test with a simple geopoly virtual table opening an in memory database SQLite3Open returned 0 open the rtree virtual table sqlcmd is: 'create virtual table newtab using geopoly(a,b,c)' SQLite3PrepareV2 returned 0 SQLite3Step failed returning 1 Extended error code is: 1 Extended error message is: no such module: geopoly SQLite3Finalize returned 1 forced to abandon testing since geopoly table could not be created- assertion documented Regards, Graham Hardman. Links: -- [1] https://github.com/govert/SQLiteForExcel ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] codeblocks thing happens when using codeblocks to compile sqlite with geopoly
Hi, I have built versions of the commandline shell and the dll so as to get access to the geopoly module. My builds were done firstly using the mingW64 compiler (from the command prompt) on windows10, and then later using codeblocks. For both builds I specified the same set of compile time directives that included SQLITE_ENABLE_RTREE and SQLITE_ENABLE_GEOPOLY. Both build sets appeared successful in that there were no error codes returned, and I could successfully create a table using geopoly, insert and manipulate the records. With my files built from the command prompt I ran the pragma compile_options and see that geopoly is listed as expected. With my files as built from within codeblocks the same test has geopoly omitted, yet as i said above the files respond to me issuing geopoly-related instructions. Can anyone make sense of this, and should i be worried? Thanks, Graham ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] clarification of the .binary option of the sqlite3 command shell program.
thanks for that. I had forgotten about taking a look at the source code.
All clear now.
Graham
On 20-10-2018 12:29 am, Jay Kreibich wrote:
On Oct 19, 2018, at 3:30 AM, Graham Hardman
wrote:
Hi,
I am curious about what this option does. It is not discussed in the
documentation and my own testing with the shell program has not aided
my
understanding. A simple example would be nice.
It controls how data is output to files/stdout.
Only relevant on Windows; does absolutely nothing on all other
platforms.
sqlite-amalgamation-3250200/shell.c:200:
/* On Windows, we normally run with output mode of TEXT so that \n
characters
** are automatically translated into \r\n. However, this behavior
needs
** to be disabled in some cases (ex: when generating CSV output and
when
** rendering quoted strings that contain \n characters). The following
** routines take care of that.
*/
#if defined(_WIN32) || defined(WIN32)
static void setBinaryMode(FILE *file, int isOutput){
if( isOutput ) fflush(file);
_setmode(_fileno(file), _O_BINARY);
}
static void setTextMode(FILE *file, int isOutput){
if( isOutput ) fflush(file);
_setmode(_fileno(file), _O_TEXT);
}
#else
# define setBinaryMode(X,Y)
# define setTextMode(X,Y)
#endif
regards,
Graham
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] geopoly data input options
Thanks very much for your prompt reply. I had seen that I could use the geopoly_blob function to copy a json-formatted entry into a new record without getting an error from sqlite, however I was disconcerted when seeing that a select _shape from newtab (using example from documentation) displayed the first record as the json string and the second record as a blob (ie []). The news about the change in next release is all good. Thanks again. regards, Graham On 20-10-2018 3:14 am, Richard Hipp wrote: On 10/19/18, Graham Hardman wrote: My question now is : must I always format my list of vertices as text ( in json format ) as shown in the documentation. No. Polygons can be either in the GeoJSON format as text, or in a binary format (https://www.sqlite.org/geopoly.html#binary_encoding_of_polygons). Any routine that accepts a polygon can accept either format. Beginning with the next release, polygons will always be stored in the binary format. In the previous release, polygons were stored in whatever format was used to insert them. But experience shows that the binary format is smaller and faster. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] clarification of the .binary option of the sqlite3 command shell program.
Hi, I am curious about what this option does. It is not discussed in the documentation and my own testing with the shell program has not aided my understanding. A simple example would be nice. regards, Graham ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] geopoly data input options
Hi, this is my first post to this group so firstly: thanks for the oportunity to be here. I have long been in awe of sqlite's power and thankful of its open source nature. I see great possibilities for me to use the shape matching functions of the geopoly module to extend an autocad vba program I have built up over say 15 years that basically tags polyline entities (representing rollers) then populates an access database with properties, automates the detail drawings and also feeds data to a cadcam machining package to make the parts. I have built special versions of the commandline shell and the dll library and shown that my ideas will succeed very well. I will relocate the polylines to the origin and looks for clones and mirror clones using the geopoly_xform method' My question now is : must I always format my list of vertices as text ( in json format ) as shown in the documentation. Of course I can do this, but it would seem to me better to pass a blob type object. i hope someone can answer this. regards, Graham Hardman ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
