Re: [sqlite] geopoly data input options
Spatialite does to Sqlite what Postgis does to Postgres. Same concepts. Noël On Sat, 20 Oct 2018 at 22:49, Jonathan Moules wrote: > More specifically, in the "Simple Features for SQL" specification: > > http://www.opengeospatial.org/standards/sfs > > and if you have access (or gobs of money), there's the ISO spec (I'm > guessing it's the same) - > https://webstore.ansi.org/RecordDetail.aspx?sku=ISO+19125-1%3A2004 > > I'd also suggest PostGIS (a PostGreSQL extension for spatial) given > they're open-source you can take a gander at their code to get a feel > for it. > > PostGIS also has a superset called "EWKB", though the docs are fairly > poor on it (I'm not sure what the "E" is for - Enhanced"?) - "PostGIS > EWKB/EWKT add 3dm,3dz,4d coordinates support and embedded SRID > information" - probably beyond the scope of what you want in geopoly at > this point. > > Cheers, > > Jonathan > > > On 2018-10-19 21:56, Noel Frankinet wrote: > > There a WKB and WKT (text) representation). > > You can probably find everything : http://www.opengeospatial.org > > Spatialite is also a good source > > . > > > > > > On Fri, 19 Oct 2018 at 22:47, Richard Hipp wrote: > > > >> On 10/19/18, Thomas Kurz wrote: > Beginning with the next release, polygons will always be stored in the > binary format. > >>> Is the SQLite binary encoding identical to the Well-Known-Binary > geometry > >>> format? > >> That might have happened, except the WKB format was not known to me... > >> Where can I find information about WKB? > >> > >> -- > >> D. Richard Hipp > >> d...@sqlite.org > >> ___ > >> 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 > -- Noël Frankinet Strategis sprl 0478/90.92.54 ___ 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
More specifically, in the "Simple Features for SQL" specification: http://www.opengeospatial.org/standards/sfs and if you have access (or gobs of money), there's the ISO spec (I'm guessing it's the same) - https://webstore.ansi.org/RecordDetail.aspx?sku=ISO+19125-1%3A2004 I'd also suggest PostGIS (a PostGreSQL extension for spatial) given they're open-source you can take a gander at their code to get a feel for it. PostGIS also has a superset called "EWKB", though the docs are fairly poor on it (I'm not sure what the "E" is for - Enhanced"?) - "PostGIS EWKB/EWKT add 3dm,3dz,4d coordinates support and embedded SRID information" - probably beyond the scope of what you want in geopoly at this point. Cheers, Jonathan On 2018-10-19 21:56, Noel Frankinet wrote: There a WKB and WKT (text) representation). You can probably find everything : http://www.opengeospatial.org Spatialite is also a good source . On Fri, 19 Oct 2018 at 22:47, Richard Hipp wrote: On 10/19/18, Thomas Kurz wrote: Beginning with the next release, polygons will always be stored in the binary format. Is the SQLite binary encoding identical to the Well-Known-Binary geometry format? That might have happened, except the WKB format was not known to me... Where can I find information about WKB? -- D. Richard Hipp d...@sqlite.org ___ 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
There a WKB and WKT (text) representation). You can probably find everything : http://www.opengeospatial.org Spatialite is also a good source . On Fri, 19 Oct 2018 at 22:47, Richard Hipp wrote: > On 10/19/18, Thomas Kurz wrote: > >> Beginning with the next release, polygons will always be stored in the > >> binary format. > > > > Is the SQLite binary encoding identical to the Well-Known-Binary geometry > > format? > > That might have happened, except the WKB format was not known to me... > Where can I find information about WKB? > > -- > D. Richard Hipp > d...@sqlite.org > ___ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > -- Noël Frankinet Strategis sprl 0478/90.92.54 ___ 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
On 10/19/18, Thomas Kurz wrote: >> Beginning with the next release, polygons will always be stored in the >> binary format. > > Is the SQLite binary encoding identical to the Well-Known-Binary geometry > format? That might have happened, except the WKB format was not known to me... Where can I find information about WKB? -- D. Richard Hipp d...@sqlite.org ___ 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
Re: [sqlite] geopoly data input options
Hmm... this seems to be different from WKB format. I was hoping that the
geopoly extension would be compatible to established formats such as Spatialite.
- Original Message -
From: Keith Medcalf
To: SQLite mailing list
Sent: Friday, October 19, 2018, 21:05:02
Subject: [sqlite] geopoly data input options
From the source:
/*
** Internal representation of a polygon.
**
** The polygon consists of a sequence of vertexes. There is a line
** segment between each pair of vertexes, and one final segment from
** the last vertex back to the first. (This differs from the GeoJSON
** standard in which the final vertex is a repeat of the first.)
**
** The polygon follows the right-hand rule. The area to the right of
** each segment is "outside" and the area to the left is "inside".
**
** The on-disk representation consists of a 4-byte header followed by
** the values. The 4-byte header is:
**
** encoding(1 byte) 0=big-endian, 1=little-endian
** nvertex (3 bytes) Number of vertexes as a big-endian integer
**
** Enough space is allocated for 4 coordinates, to work around over-zealous
** warnings coming from some compiler (notably, clang). In reality, the size
** of each GeoPoly memory allocate is adjusted as necessary so that the
** GeoPoly.a[] array at the end is the appropriate size.
*/
typedef struct GeoPoly GeoPoly;
struct GeoPoly {
int nVertex; /* Number of vertexes */
unsigned char hdr[4]; /* Header for on-disk representation */
GeoCoord a[8];/* 2*nVertex values. X (longitude) first, then Y */
};
---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a
lot about anticipated traffic volume.
>-Original Message-
>From: sqlite-users [mailto:sqlite-users-
>boun...@mailinglists.sqlite.org] On Behalf Of Thomas Kurz
>Sent: Friday, 19 October, 2018 09:17
>To: SQLite mailing list
>Subject: Re: [sqlite] geopoly data input options
>> Beginning with the next release, polygons will always be stored in
>the
>> binary format.
>Is the SQLite binary encoding identical to the Well-Known-Binary
>geometry format?
>___
>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
From the source:
/*
** Internal representation of a polygon.
**
** The polygon consists of a sequence of vertexes. There is a line
** segment between each pair of vertexes, and one final segment from
** the last vertex back to the first. (This differs from the GeoJSON
** standard in which the final vertex is a repeat of the first.)
**
** The polygon follows the right-hand rule. The area to the right of
** each segment is "outside" and the area to the left is "inside".
**
** The on-disk representation consists of a 4-byte header followed by
** the values. The 4-byte header is:
**
** encoding(1 byte) 0=big-endian, 1=little-endian
** nvertex (3 bytes) Number of vertexes as a big-endian integer
**
** Enough space is allocated for 4 coordinates, to work around over-zealous
** warnings coming from some compiler (notably, clang). In reality, the size
** of each GeoPoly memory allocate is adjusted as necessary so that the
** GeoPoly.a[] array at the end is the appropriate size.
*/
typedef struct GeoPoly GeoPoly;
struct GeoPoly {
int nVertex; /* Number of vertexes */
unsigned char hdr[4]; /* Header for on-disk representation */
GeoCoord a[8];/* 2*nVertex values. X (longitude) first, then Y */
};
---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a
lot about anticipated traffic volume.
>-Original Message-
>From: sqlite-users [mailto:sqlite-users-
>boun...@mailinglists.sqlite.org] On Behalf Of Thomas Kurz
>Sent: Friday, 19 October, 2018 09:17
>To: SQLite mailing list
>Subject: Re: [sqlite] geopoly data input options
>
>> Beginning with the next release, polygons will always be stored in
>the
>> binary format.
>
>Is the SQLite binary encoding identical to the Well-Known-Binary
>geometry format?
>
>___
>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
> Beginning with the next release, polygons will always be stored in the > binary format. Is the SQLite binary encoding identical to the Well-Known-Binary geometry format? ___ 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
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. -- D. Richard Hipp d...@sqlite.org ___ 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
