[rttopo-dev] Graph Theory vs rttopo

[Brian M Hamlin]

Hi Andrea -
 
  in the past, I have referred to a document   OGC 06-103r3   this 
copy dated 2006, ver 1.2
Upon reading your email, I now have a document open called     
ISO/IEC CD 13249-3:201x(E)
  dated 2009, fourth edition

 The ISO document is larger than what i had seen before, and includes 
each ST_xxx call. 
Is it fair to say, that these standards implement  "types" 
 "predicates" (verbs)  and "interface" (ST_xxx)  ?

  a quick scan of this (750 page) document for the word "distance" 
shows the GEOMETRY distance,
which is good news to me.. I am suggesting geometry distance is very 
important for common use.. 

  I will read through some of this large ISO document regarding 
"Topology-Geometry"  (e.g. chapter 10)
and look for the ambiguity mentioned.. 

  Particularly, this rttopo library will have an interface defining 
entry points, and the names of those 
entry points, and the descritpions of those services, perhaps make a 
place for good choices early in the project. 

  Secondly, I now have a copy of the rttopo code repository, and I can 
see that this is a long-standing work, with 
quite a bit of completed functionality.. so I will look into that 
more.. Sandro knows that I have done some
investigation of the exact details of liblwgeom under PostGIS, in 
addition to non-trivial problem solving with
PostGIS itself. So the material in rttopo is not entirely new to me.. 

  thank you for your quick reply
  best regards from Berkeley, California
  Brian M Hamlin

ps- your english is quite readable..   :-)

On Sun, 1 May 2016 22:09:24 0200, Andrea Peri <aperi2007 at gmail.com> wrote:

I apologize for my poor english. 
So I hope to understand correctly your question. 

Is I understand correctly you:
Our main reference is the ISO 13249 document. 
In that document there are effectivelly two kind of topology concepts:
the topologyGeometry and the topologyNetwork. 

Our first and actual goal for the librttopo library is to support a
TopologyGeometry ISO13249 implementation. 
With more other functions from postgis topology to have a robust and
sufficient affordable envirnment fo r allow at specific engines to
implement topologyGeometry capabilities. 

Our test envirornment is spatialite. 
But we try to maintain a name level compatibility with postgis to
allow a more easy support of this library in postgis is someone like
to do this. 

Actually the topologynetwork is available as a specific implementation
in the spatialite implementation with the librttopo library. 
But t is a specific spatialite evolution not supporting at now from
librttopo project e not referred to any ISO documents. 

In a future when we start to support the network the dstinguish will
follow the ISO13249 reference where the Network function has all the
NET suffix. 

And so we could easibly suppose that when we will add a function that
is not in the ISO docs, but is referred to the NETwork it will have
the NET suffix in it name. 

Regards,

Andrea Peri. 

2016-05-01 19:58 GMT 02:00 Brian M Hamlin <maplabs at light42.com>:
> With the name 'topo', connectivity of nodes must be an important 
> design direction here. 
> Perhaps some naming decisions early could make the library more 
> usable and clear .. 
>
> for example, distance (d) in graph theory is the number of "hops" 
> between nodes, yet geodata constantly refers to distance as a 2D (or 
> more) measure. What kinds of naming could make this fundamental 
> distinction clear, for everyday use ? Are there other naming 
> examples, moving away from graph theory, towards more applied geodata 
> ?
>
> --
> Brian M Hamlin
> OSGeo California Chapter
> blog.light42.com
>
> _______________________________________________
> librttopo-dev mailing list
> librttopo-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/librttopo-dev

-- 
-----------------
Andrea Peri
. . . . . . . . . 
qwerty àèìòù
-----------------

--
Brian M Hamlin
OSGeo California Chapter
blog.light42.com