Defining geometry by other features

[Darryl Bailey]

Hi,

I'm very, very new to SpatiaLite, and I really struggled to put a
subject to this query which is most probably best illustrated with an
example.

I am wanting to define a polygon feature, which is composed of line
features from another layer, and these line features are defined by
point features from yet another layer. So therefore - if I change the
coordinate of the point feature then the line and polygon features are
automatically corrected as they reference this point feature. Is this
possible?

In other words I would like to have as my geometry the id of a point
feature for the start and end coordinates of my line features, instead
of the actual numerical coordinate.

Or is this deving into the world of object oriented GIS?

Thanks
Darryl

[a.furieri]

Hi Darryl,

what you are attempting to do isn't at all silly or crazy.
this approach exists since many years, and is usually
known as Topology.

This is really much more hard to implement than "standard"
OGC-SFS Geometries are: and obviously it's really slower to
be processed (simply imagine the desperate work required
each time that a complex polygon has to be reassembled
from a sparse collection of points and lines ...).

Historically "closed" sw as ArcINFO, and "open" sw as
GRASS are fully based on Topology-geometries: anyway
both them are really complex and highly sophisticated
"professional" packages.

PostGIS will soon support a really good Topology:
and for sure SpatiaLite as well will include some
(limited) support for Topology into the next-to-be-released
v.3.0-STABLE
... work still in progress ...

this very recent post can give you several useful
hints about Topology and v.3.0 ;-)
http://www.gaia-gis.it/GEOS-advanced.pdf
[ST_Collect, ST_MergeLines, ST_BuildArea ...]

bye Sandro

[Darryl Bailey]

Hi Sandro,

Thank you for your reply, and it really is a great answer. I didn't
even think about processing time and how it could be affected. I
reckon that mostly users would need their GIS to process and view
data, and little in the way of updating, or regularly changing actual
spatial data (especially where linked topology is concerned).

Processing time is normally more valuable than storage space, and I
suppose a good work around would be to have a database that holds the
topology which would then be used to create the actual file or spatial
tables used by a GIS. It may double up on storage space, but will not
affect the usual processing time as these files/tables would remain
the same. If the two datasets are housed in the same database (as
opposed to say the GIS data being held as shape files), then once the
spatial dataset has been created, the only records affected from there
on out are those that need amendments. So there shouldn't even be
that much downtime keeping the data in sync, nor affecting multiusers
too much. Unless one needs to do a complete re-adjustment of coords -
for example manholes which need to be updated to GPS coords which were
previously digitised off maps. But then this is an understandable
downtime.

Now you have my old rusty brain thinking again.

Once again, many thanks for the reply,
Darryl

> hints about Topology and v.3.0 ;-)http://www.gaia-gis.it/GEOS-advanced.pdf

[a.fu...@lqt.it]

On Fri, 22 Jul 2011 05:18:45 -0700 (PDT), Darryl Bailey wrote

> Processing time is normally more valuable than storage space, and I
> suppose a good work around would be to have a database that holds the
> topology which would then be used to create the actual file or
> spatial tables used by a GIS.
>

Darryl, you are reading my mind :-D

more or less, the SpatiaLite own support
for Topology will follow exactly the above
guidelines, i.e.:

* a coordinate set of relationally joined Topology
tables (Nodes, Edges, Faces / Curves, Surfaces)
* to be easily transformed into "materialized views",
i.e. "ordinary" Spatial Tables based on conventional
OGC-SFS Geometries (Points, Linestrings, Polygons ..)

Your idea about applying any subsequent update only
to 'child' objects strictly depending on the changed
'topological parent' (and not to the dataset as a whole)
is really great.
Not really sure if this could be actually implemented
immediately in v.3.0: but surely a big suggestion for
any further development to come: thanks a lot.

bye Sandro

[julio menezes]

2011/7/22 Darryl Bailey <darryl...@gmail.com>:
> Hi,

>
>
> So therefore - if I change the
> coordinate of the point feature then the line and polygon features are
> automatically corrected as they reference this point feature.  Is this
> possible?
>
> In other words I would like to have as my geometry the id of a point
> feature for the start and end coordinates of my line features, instead
> of the actual numerical coordinate.
>
> Or is this deving into the world of object oriented GIS?
>
> Thanks
> Darryl
>

Hi Darryl,

Very good question !

I'm new to SQL and GIS, learning by myself and by the lists. I,
yesterday, posted in a QGIS forum, the same question. About foreign
land borders of properties from a cloud of points of an adjused GPS
network. (If correcting a GPS point, automatically correct the
competing lines). If there is duplication of coordinates between
layers, this can lead to disastrous inconsistencies (in my view).

I will be follwing this thread,

In a sense GNU, this time, I want to thank Sandro for his fine work.
** tks Sandro **

regards,

julio menezes ( from BraSil )

(__)
(oo)
\../

[giohappy]

I've just joined this group, and I'm very glad to see this as the
first discussion.
I have a question related to the topology model implementation in
Spatialite. As a comparison, both Oracle Spatial and Postgis
implements a topological model but OS relates directly an existing
"feature table" to the topological tables through a table which
mantains the relations [1], while Postgis lets you create/derive a
geometrical (SFS) object from a topo object [2]. What are the
peculiarities of Spatialite's implementation? It seems to resemble
Postgis' way, in which case I suppose that any change to the
geometrical object (which currently most GIS software deal with) won't
affect the relative topological object, is it right?
Anyway the idea of a composition model woul be very interest to
deepen...

giovanni

[1] http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14256/sdo_topo_concepts.htm#BABBBDBJ
[2] http://trac.osgeo.org/postgis/wiki/UsersWikiTopoGeometry

On 22 Lug, 15:57, julio menezes <yjmene...@gmail.com> wrote:
> 2011/7/22 Darryl Bailey <darrylsur...@gmail.com>:

[Andrea P.]

Hi,

the topology approach of postgis approach is fully compliant to the
ISO13249 specs.

> Postgis' way, in which case I suppose that any change to the
> geometrical object (which currently most GIS software deal with) won't
> affect the relative topological object, is it right?

AFAIK yes.

> Anyway the idea of a composition model woul be very interest to
> deepen...

yes I also like this approach.

On 23 Lug, 01:16, giohappy <gioha...@gmail.com> wrote:
> I've just joined this group, and I'm very glad to see this as the
> first discussion.
> I have a question related to the topology model implementation in
> Spatialite. As a comparison, both Oracle Spatial and Postgis
> implements a topological model but OS relates directly an existing
> "feature table" to the topological tables through a table which
> mantains the relations [1], while Postgis  lets you create/derive a
> geometrical (SFS) object from a topo object [2]. What are the
> peculiarities of Spatialite's implementation? It seems to resemble
> Postgis' way, in which case I suppose that any change to the
> geometrical object (which currently most GIS software deal with) won't
> affect the relative topological object, is it right?
> Anyway the idea of a composition model woul be very interest to
> deepen...
>
> giovanni
>

> [1]http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14256/sdo_to...

[G. Allegri]

2011/7/23 Andrea P. <aper...@gmail.com>

Hi,

the topology approach of postgis approach is fully compliant to the
ISO13249 specs.

I haven't had the opportunity to read the SQL/MM specification (some day I will buy it maybe...), but I imagine that the sql implementation follows the ISO 19107 Spatial Schema. Am I right?
 

One of the porpuses of the Topology Package (as it's defined in ISO 19107) is to "port" geometrical computations (on geometries) to combinatorial algorithms (on topologies), with all the benefits (and complexities!), like accelerated computations, it bring. But, actually, the computational libraries commonly used work on the geometrical model, and most of the widespread GIS softwares don't treat topological structures. This are obvious things, but I feel that one important feature to understand better is the sync between the two models. I mean, when a (not topological) GIS editing is being used, like with qgis/gvsig/arc*/etc., the geometrical feature will loose its sync with the topological one it derives from. What does this implicate to data consistency? One step before:the db user/client is in charge of managing this, not the db. Ok, but what if this doesn't happen? The geometrical "realization" (or one of the many realizations) of the topo object are not statical objects, as their existence and structure is related to the topological primitives and complexes.

I wonder on this just to better understand better how the topological derived objects are supposed to be used and managed.
Cheers,
giovanni