geopoly data input options

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

geopoly data input options

Graham Hardman
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
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: geopoly data input options

Richard Hipp-3
On 10/19/18, Graham Hardman <[hidden email]> 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
[hidden email]
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: geopoly data input options

Thomas Kurz
> 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
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: geopoly data input options

Keith Medcalf

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-
>[hidden email]] 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
>[hidden email]
>http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users



_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: geopoly data input options

Thomas Kurz
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 <[hidden email]>
To: SQLite mailing list <[hidden email]>
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-
>[hidden email]] 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
>[hidden email]
>http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users



_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: geopoly data input options

Graham Hardman
In reply to this post by Richard Hipp-3
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 <[hidden email]> 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
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: geopoly data input options

Richard Hipp-3
In reply to this post by Thomas Kurz
On 10/19/18, Thomas Kurz <[hidden email]> 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
[hidden email]
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: geopoly data input options

Noel Frankinet-3
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 <[hidden email]> wrote:

> On 10/19/18, Thomas Kurz <[hidden email]> 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
> [hidden email]
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>


--
Noël Frankinet
Strategis sprl
0478/90.92.54
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: geopoly data input options

Jonathan Moules-3
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 <[hidden email]> wrote:
>
>> On 10/19/18, Thomas Kurz <[hidden email]> 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
>> [hidden email]
>> _______________________________________________
>> sqlite-users mailing list
>> [hidden email]
>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>>
>


_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: geopoly data input options

Noel Frankinet-3
Spatialite does to Sqlite what Postgis does to Postgres.
Same concepts.

Noël

On Sat, 20 Oct 2018 at 22:49, Jonathan Moules <[hidden email]>
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 <[hidden email]> wrote:
> >
> >> On 10/19/18, Thomas Kurz <[hidden email]> 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
> >> [hidden email]
> >> _______________________________________________
> >> sqlite-users mailing list
> >> [hidden email]
> >> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> >>
> >
>
>
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>


--
Noël Frankinet
Strategis sprl
0478/90.92.54
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users