[rttopo-dev] reserving face identifiers for state flags

[Sandro Santilli]

Following the announced work on rtt_AddLineNoFace, I've been
looking at an rtt_RegisterMissingFaces function (may be renamed
in future as rtt_Polygonize) to re-construct all the faces.

For easier testing, I've drafted an implementation of it
in PostGIS/liblwgeom, which can be seen here:
https://git.osgeo.org/gogs/strk/postgis/src/batch-topo

The new function uses the backend callbacks not only to extract
the data but also to save intermediate states (like a "visited"
like flag). In particular the states are:

 1. An indication of an edge side still not being visited
    (a null value on its <side>_face attribute).

 2. An indication of an edge side being part of an hole
    of a yet to be assigned face
    (an hard-coded value on its <side>_face attribute)

So basically the "left_face" and "right_face" attributes of the edges
are being (mis)used by the librttopo library for book-keeping.

As a backend might refuse to allow a <side>_face value which does not
exist in the <face> table, the library also creates a "placeholder"
face there with the hard-coded identifier.  Shall the backend topology
already have a face with the hard-coded value for "unassigned face",
the backend would raise an exception there, making the process fail.

Thus I think it would make sense to define some identifiers as
"reserved" and require applications not to use them.

It could be convenient to say that any negative face_id would be
reserved, so that the library could make up a large number of
values with all different meanings, even if there isn't a need
for so many values. What do you think ?

It also has to be considered that value "-1" for edge "left_face" and
"right_face" already has the special meaning of representing a NULL when
talking with the backend, making it impossible to request setting it to
a real "-1" value, so if we want to go sequencially, -2 could mean
"unassigned face", or more generally "unknown face". At the time of
writing I'm using MIN_INT64 as such value instead.

NOTE: using a "null" for "unknown" would actually make the most sense
      here, but it has a drawback: I'm already using NULL for
      determine which edges were visited and which not [could be
      solved by using an in-process data structure].

NOTE2: in the near future such "unknown face" value might be also
       used to mark isolated nodes during the polygonization.


--strk;