Hey all, Hey Sandro.
The first beta version of the function is completed. ** GetRelatedTopogeom(source_topo topogeometry, target_topo_layer_id INT); ** It returns set of topogeometry of the layer target_topo_layer_id that may be affected by a change in topogeometry source_topo. I consider it a mandatory function to be able to work consistently at the topogeometry level, with multiple related topogeometry. I'm entering testes, somebody has test db for postgis_topology? I would need 2 topogeom layers of type puntal, lineal, areal ( 6 total). I'm starting the test on my own data even if it is not ideal Cheers, Rémi-C 2013/10/23 Rémi Cura <[email protected]> > I wrote down all the cases and here is the conclusion : > > *When looking for topogeom B related to topogeom A, we should get all > elements of B which may be impacted by a change in A.* > This definition of relation is much more clear and precise. > > So with this new definition, > > getting puntal/lineal/areal impacted by a change on a point is to take all > node impacted (one) / all edge impacted by this node / all faces impacted > by all edges impacted by the node. > > Same for a change in lineal or in areal. > > I'll re-code in this way. > > Cheers, > > Rémi-C > > > 2013/10/23 Rémi Cura <[email protected]> > >> Hmm it can't work, >> >> please do not consider the previous message, i'm doing changes. >> >> Cheers, >> Rémi-C >> >> >> 2013/10/23 Rémi Cura <[email protected]> >> >>> Just to be sure could you validate please? >>> >>> The way I intend to find a source topogeom is related to target topogeom >>> is like this (in sql pseudo code): >>> >>> element_id is supposed to be the element_id found in the relation table >>> regarding *source* topogeom : >>> Example : what are the (lineal) target topogeom related to the (puntal) >>> source topogeom : >>> >>> `SELECT abs_next_left_edge UNION SELECT abs_next_right_edge >>> WHERE element_id = start_node OR element_id = end_node` >>> >>> >>> with the following >>> target >>> >>> puntal : SELECT start_node UNION SELECT end_node >>> lineal : SELECT abs_next_left_edge UNION SELECT abs_next_right_edge >>> areal : SELECT left_face UNION SELECT right_face >>> >>> >>> source: >>> >>> puntal : WHERE element_id = start_node OR element_id = end_node >>> lineal : WHERE element_id = abs_next_left_edge OR element_id = >>> abs_next_right_edge >>> areal : WHERE element_id = left_face OR element_id = right_face >>> >>> >>> >>> This may not be the optimal (we could use shortcut with edge_id), but it >>> is symmetric in every way. >>> >>> Cheers, >>> Rémi-C >>> >>> >>> 2013/10/23 Rémi Cura <[email protected]> >>> >>>> Function getRelated is working for getting lineal related to a given >>>> puntal topogeom, >>>> now I'm trying to generalize so to be able to get any topogeom related >>>> to any topogeom, whatever the feature_type. >>>> >>>> Cheers, >>>> >>>> Rémi >>>> >>>> >>>> 2013/10/22 Rémi Cura <[email protected]> >>>> >>>>> OK, >>>>> >>>>> for my private function I don't expect several topogeom columns in one >>>>> table. >>>>> I can correct the getlayerid function but I don't think other people >>>>> than me need it. >>>>> >>>>> For the GetRelated, I have a working query and I'm now trying to make >>>>> it a plpgsql function >>>>> >>>>> Cheers, >>>>> Rémi-C >>>>> >>>>> >>>>> 2013/10/22 Sandro Santilli <[email protected]> >>>>> >>>>>> On Tue, Oct 22, 2013 at 05:17:55PM +0200, Rémi Cura wrote: >>>>>> > I'm sorry for being so disorganized, >>>>>> > I lack experience with postgis_topology. >>>>>> > >>>>>> > It is only the 3d function I write for it. >>>>>> > >>>>>> > I was supposing you would need the layer_id in case there are >>>>>> multiple >>>>>> > topogeom columns in one table. >>>>>> > >>>>>> > Still I don't see a use case for having multiple topogeom columns >>>>>> in the >>>>>> > same table, even if I do use multiple geom columns for one table >>>>>> sometimes. >>>>>> > >>>>>> > I totally agree with your others conclusions and proposed signature >>>>>> > SET OF topogeometry GetRelatedLineal( >>>>>> > a_source_lineal_topogeom TOPOGEOMETRY, >>>>>> > a_target_puntal_topogeom_layer_id INT ) >>>>>> >>>>>> Note that there's no problem with having multiple TopoGeometry >>>>>> columns in >>>>>> the same table, as long as you reference a each column (layer) by the >>>>>> "topology_id"/"layer_id" pair (topology.layer primary key). >>>>>> >>>>>> > I don't like to put layer_id directly as input in function because >>>>>> it is >>>>>> > not a number user fixed. >>>>>> >>>>>> In that case you can specify (schema_name, table_name, >>>>>> feature_column), >>>>>> which _also_ identifies rows in topology.layer. >>>>>> >>>>>> > I think I can live with that as I wrote a function to get layer id >>>>>> from the >>>>>> > topogeom name : >>>>>> > public.rc_getlayerid(layer_name text, layer_schema text DEFAULT >>>>>> ''::text) >>>>>> >>>>>> Missing a column name here ? >>>>>> >>>>>> --strk; >>>>>> _______________________________________________ >>>>>> postgis-devel mailing list >>>>>> [email protected] >>>>>> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel >>>>>> >>>>> >>>>> >>>> >>> >> >
_______________________________________________ postgis-users mailing list [email protected] http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users
