Re: Requirement for topological data?

I can see two ways this may be handled:
1) serialisation of geometry and topology using GML and/or any other other
serialisation with support for topology.
2) Domain models with explicit topological relationships expressed

In the case of hydrology, which I'm most familiar with, the general case is
that the geometry is "not safe" to express topology, its basically an
observation of how the water may flow to realise a topology, rather than
the way to express that topology. Such observations are scale and
time-dependent, and may have internal topology, but the topology that can
be used for processing needs to be in the domain model.

So the requirement exists but is it a new requirement? Is just analagous to
using a polygon instead of a bounding box to represent a features spatial
extent - just a choice of expressiveness.

I think an anti-pattern would be to create ad-hoc ways to handle topology
rather than using the available serialisations standards.

Maybe some of the INSPIRE schemas can be used as a BP in this case? (i'm
not familiar with the cadastral data products).

Rob

On Fri, 23 Sep 2016 at 20:55 Frans Knibbe <frans.knibbe@geodan.nl> wrote:

> Hello,
>
> This is a message I intended to send to this group, but I just noticed I
> sent it to another (non-existent, as far as I can tell) address.
>
> Regards,
> Frans
>
> ---------- Forwarded message ----------
> From: Frans Knibbe <frans.knibbe@geodan.nl>
> Date: 31 August 2016 at 14:28
> Subject: Requirement for topological data?
> To: "sdwwg@lists.opengeospatial.org" <SDWWG@lists.opengeospatial.org>
>
>
> Hello all,
>
> In general I do not like to assign myself more work, but I do wonder if
> there is yet another requirement that we have forgotten to identify. It
> could go something like this:
>
> It should be possible to publish and use topological geometric data on the
> web.
>
> To be clear, I mean something else than the ability to assert topological
> relationships between spatial things (e.g. A is contained by B) or to use
> topological functions in queries (e.g. give me all geometries touching
> geometry B). This is about maintaining the topological awareness in
> geometric datasets, as supported by data stores like PostGIS
> <http://postgis.net/docs/Topology.html> and Oracle Spatial
> <https://docs.oracle.com/cd/B19306_01/appdev.102/b14256/sdo_topo_concepts.htm>.
> As an example, a line geometry could be aware that it functions as a border
> between two municipalities and as a border between two provinces. And the
> line 'knows' which polygons are on its left and which polygons are on its
> right, and to which other lines it is connected. GIS data stores can have
> extended data models to deal with this extra level of information, next to
> the bare geometry. An interchange format exists for topological geometric
> data: TopoJSON <https://github.com/mbostock/topojson/wiki>.
>
> I think that whatever standards or recommendations we come up with,
> working with topological geometric data on the web should be possible and
> should at least not be hampered in any way. So that is why it would be good
> to have this extra requirement.
>
> I stumbled upon the topic when I talked with a colleague about vector
> tiling (publishing vector geometry as a pyramid of tiles, just like is done
> with map images). For that to work, good generalization of geometry is
> required and for good generalization topological awareness is required,
> because in general you don't want generalisation to change topological
> relationships.
>
> More in general, generalisation of geometry is necessary for limiting the
> bulk of geometry on the web and giving consumers the opportunity to request
> or filter data with an appropriate level of detail. So that at least is
> some sort of use case for the requirement.
>
> Regards,
> Frans
>
>
>
>