Proposal talk:Multilinestring

can we close a multilinestring ?

And if yes, what makes the difference with a multipolygon relation ? --Pieren 13:51, 26 January 2012 (UTC)

Here is pieren, with always the good questions ;-). So yes, it is a very good and important question, and I'm happy that you have asked it. sletuffe 15:29, 26 January 2012 (UTC)

And if yes, is it possible to have self intersecting multilinestrings in opposition to multipolygons where it is not allowed (geometry error). --Pieren 16:11, 26 January 2012 (UTC)

no sletuffe 16:18, 26 January 2012 (UTC)

I was wrong, the answer is yes see [1] sletuffe 22:11, 15 May 2012 (BST)

For the previous question, I'm unsure, but if I wich to be fully compliant with the OGC, then the answer is no sletuffe 16:18, 26 January 2012 (UTC)

Seams in the end that the OGC doesn't forbids a linestring to have it's first and last point the same, then

the answer become "yes" . Basically, it means we can build round-about with that, but it will still be a line, not an area, for wich type=multipolygon are more suitedsletuffe 12:40, 27 January 2012 (UTC)

does a single relation contain several multilinestring's ?

(I mean strings that are not connected to each other) -- Pieren 13:52, 26 January 2012 (UTC)

Yes, just like the OGC propose, but to be precise, "it can", but it is optionnal. I suppose it will be like multipolygons, there are more single polygon that multiple, but I don't want to diverge from the OGC on that. sletuffe 15:32, 26 January 2012 (UTC)

Then, is it allowed to have an intersection in the multilinestring, e.g. three branches drawing an 'Y' shape (I mean, a multilinestring with more than two ends) ?

and no sletuffe 16:18, 26 January 2012 (UTC)

After more carefull reading of the OGC specification, it seams that touching multilinestring in a 'Y' shape is to be considered valid, but not 'simple'

here is a bounch of examples of the "validity" and "simple" concept : [2] sletuffe 22:10, 15 May 2012 (BST)

Orientation of multilinestring

Can this be used for types that need an orientation (e.g. a river). If it can, what is the orientation? Is it the orientation of every way as is, or is it the order of ways in the relation. --Sanderd17 14:25, 24 June 2012 (BST)

"the ordering of the way in the relation shouldn't matter", however, I see no reason for someone to order them in order to add an orientation, but for the case of the river, I whould suggest that the members ways themself should be oriented the way the river flows, and then, it shouldn't be needed to order member of the relation (which is not allways easy if the relation is very big) sletuffe 13:33, 25 June 2012 (BST)

The ordering ordering should not matter if the multilinestring is only used to close a multipolygon referencing it ; in that case, the direction/orientation of member ways in the multilinestring may also matter, but only if this is meaningful for the external relation referencing the multilinestring.

But it would matter if the multilinestring (representing for example the part of a river flow within a country where it has a distinct official name in a language, or a distinctive national reference) is used in another object whose interpretation is oriented (for example where the multilinestring is included as a member of a "waterway=*" relation with a "main_stream" or "side_stream" role, where the "waterway=*" relation represents the full river).

The ordering (and direction) of members in the multilinestring won't matter if the multilinestring represents only a part of some riverbanks (which are not necessarily closed in the multilinestring), because they are intended to be closed only in a more complete multipolygon relation, where its full list of member riverbanks is closed).

— Verdy_p ^(talk) 01:02, 23 October 2012 (BST)

Explanation of how to use multilinestring in a multipolygon or boundary

Hi, I reverted this edit : [3] not because I think it isn't good, but because it doesn't belong to this page. This page explains how to tag multilinestring, the above mentionned edit express how to tag a multipolygon using it, and I think it should be move to a "multipolygon" page. sletuffe 08:05, 23 October 2012 (BST)

You're wrong, this was NOT describing the creation of a multipolygon itself, but only as way to use multilinestrings in an external relation (including other multilinestrings, or multipolygons, or other types of relations).

The key to place that here was that this was pertinent about "where to reference a multilinestring ?" (of course this will be another OSM relation) and "what is the meaning of combining several multilinestrings? in another relation".

It was also focusing the fact that members of a multilinestring have NO "inner" or "outer" roles, given that they play both roles simultaneously.

Whatever, please don't add this on this page, either on the relations pages that describe the use of "multilinestring" or on a separate page that you can link from here, but not directly in. This is to keep this page readable. The Relations/Proposed/boundary segment is a good example of how to link this page. sletuffe 14:17, 4 December 2012 (UTC)

However, multilinestrings, just like ways, DO HAVE a direction (this is the direction of the way by default), but it may be necessary to pecify that the multilinestring uses a way in the "opposite" direction (instead of the "same" direction), using a role. This is similar to the flow direction of rivers (for the "main_stream" or "side_stream" roles), or direction of routes along highways, railways, maritime ways, or even along rivers (for the "foreward" and "backward" directions). So the ordering of elements is still significant to declare how they connect in an ordered graph.

One problem is that when you reverse the direction of the way, this role should be switched between "same" and "opposite". There are good reasons why the direction of member ways may not match the intended direction of the multilinestring.

For now this definition of multilinestrings are not capable of describing oriented graphs without using roles (not only on unclosed member ways, but also for closed ways, to be able to specify a "left" side and a "right" side from the definition of the multilinestring

Note this is a known caveat of the OGC Simple Features.

Note also that this is also true when defining multipolygons : not only the member rings an "inner" and " "outer" area in their definition plane, but they also define an "above" and "below" direction for their use as "facets" in 3D objects.

In OGC, facets delimited by rings are oriented as well, and this allows building multipolygons (assembling multiple facets in the same place, provided that these facets have no intersection with a non-null surface), or any surfacing polyedra (removing the constraints of facets being in the same plane allows representing the surface of unclosed polyédras (e.g. the three axis planes or a facetted paraboloid) or closed polyedras (such as the surface of a facetted dice or sphere including when it is concave such as a facetted 3D ring).

For correct definition of multifacet objects, you need first to orient the facets so they safely represent their surface, and then you get an unoriented multifacet object. But this multifacet alone still does not have an orientation, and so you need another orientation to define the "front" and "back" side, without changing the definition of the surface convered by the facet itself.

If you an define a "front" and "back" face on every side of a facet, then only you can use them to define unoriented volums (with their "inner" and "outer" volumes.

Note also that another way to define volumes without using facets is to use a unitary oriented vector definining the direction of the normal to a facet, and the smallest distance of the place to the origin

In other words, each facet of any closed volume has 2 freedom degrees (think about polar coordinates on a sphere to orient the unit vector), plus 1 for the distance, so 3 parameters per facet is enough, which is ompletely equivalent to using a SINGLE node for each facet delimiting the volume, instead of the complete definition of its outer ring

E.g. consider a condave object similar to a 3D ring : take the cubic dice with a hole created by a triangular bar passing through two opposite cubic faces, it is a volume with 9 facets which is fully described by an unordered set of 9 nodes only, at the center of each plane facet (including the two concave facets with their hole) — but paradoxally, it's NOT fully defined by its unordered set of 14 vertice nodes, because these nodes may be grouped arbitrarily to define several other closed or unclosed 3D objects or mutliple surfacic polyedrons.

In the general case where a 3D volume is concave, you need to position and orient its facets (independantly of the orientation used for the facet outer rings, which is no longer significant except to bound them in their own plane) : but oriented facets are exactly like oriented planes, which are in fact defining a volume covering one half of the full 3D space (just like lines in a plane are splitting the place in two parts). This is the "dual" definition of volumes using an unordered set of segments fro mthe origin)

Now volumes are defined as the non-empty intersections, or union, of these half-spaces (choosing "intersection" rather than "union" also allows you to orient these volumes after its construction and closure (of the combination of these oriented half-wpaces its still infinite, the volume is not closed, otherwise it is closed but it may be empty; using zero nodes to define the volume means the full space; using three distinct but aligns points is enough to specify the empty space, but its has too much freedom, and it's best to defining the mpty space by changing the orientation of the full space), because only one orientation has a finite volume (the validity constraint being that this finite volume exists either in the intersection or in the union, which means that even the previous).

This definition of volumes using their dual representation based on nodes relatie to the origin, is similar to the definition of lines with its dual (a single node, where the the lines passes through and is orthogonal to the other line passing by this point and the origin, plus only 1 finite boolean which orients it). Dual spaes allow counting the effective degrees of liberties : 3 degrees for 3D points as well as for 3D lines (3D points and 3D lines are dual subspaces in the same 3D space), 4 degrees for 3D planes.

This transform is similar to when we use polar coordinates (only as angles in bounded ranges plus only one non-null sizing/zooming factor, or arbitray angles and the null sizing/zooming factor) instead of cartesian coordinates (same number of parameters except they are unbounded, the effect of bounding playing no role on the dimension of the object), plus one boolean parameter to orient it.

Geometric "simple features" should really make this obvious:

• Dimension 0 (points): as many parameters as there are dimensions in the global space, for each node, plus 1 boolean to orient them (i.e. include or exclude them). This defines "points", and "polypoints" (constraint: containing only a finite set of distinct points in arbitrary order). "segments" and "multilinestrings" are also defined in that dimention 0 as they are dual to polypoints to which you have added a finite number of possible permutations.
• Dimension 1 (continuous curves with infinite lengths) : add only 1 free parameter to the parameters of polypoints. This defines "lines" (not straight lines, but arbitrary polynomial curves with), and "multilines" (constraint: containing only a set of distinct lines in arbitrary order). "facets" and "mutlifacets" (i.e. finite surfacic polyedrons) are also defined at this level. If you already have the boolean parameter (i.e. the orientation), this remains at dimension 1 but allows you to define finite volumic polyedrons). This dimension 1 is not needed when working in a 2D global space (i.e. like in OSM, with just spheric polar coordinates and no elevation).
• Dimension 2 (continuous surfaces with infinite area) : add only 1 free parameter to the parameters of lines or mutilines. Not needed for geographic system (except is we encode time, i.e. the global space is at least 4D).

In other words, OSM currently ONLY objects described topologically in dimension 0 (ignore the dimensions of the global physical space where discrete points are measured, this dimension is arbitrary and in fact not really known, even if for us humans it appears as 3D, or 2D in flat maps; in other words, ignore the arbitrary choice of geographic projection, i.e. the choice of geoid and of the measurement unit) ; ALL objects in OSM (even the most complex ones) defined works with

• only discrete points (nodes) first arranged in unordered sets with a finite number members,
• then an optional linear interpolations of them (but only if these discrete points are ordered in a finite set of circular permutations) within a static bounded 1D range [0..1] or the static set {0, 1}
• then the optional fixing of a starting point within the previous circular permutations in order to eliminate the linear interpolation from the last point back to the to the first one)
• and an optional boolean-only orientation

  But most of these interpretations are implicit as soon as we need to store lists of nodes in a serialization and a given permutation and with an implicit starting node; so we need specific subclass types, to remove these implicit interpretations as "ordered" (where all nodes have two distinct neighbour nodes and the closure of neighbourhood contains all nodes), "oriented", "started" (two nodes in the ordered list have only 1 neighboor) and "interpolated" (to create straight segments joining the discrete points).

  The 3 flags "oriented", "started" and "interpolated" are meaninful only if the "ordered" flag is true and there are more than 1 node defined in the object : these 3 flags define 8 subclasses; with the "unordered" flag you have 8 + 1 = 9 "multi-xxxx" subclasses, plus the "node" class; i.e. a total of 10 geometric primitives for all possible OSM objects, excluding relations (more than what "OGC Simple Features" currently defines, which explains why we have "validation errors" when converting OSM data to OGC data)

  There's no dfference between the OSM "node" object and the OGC "point" object, but an OSM "way" already has 8 possible interpretations when OGC has only 1 interpretation for each of its defined basic primitives using multiple points.

  And this becomes much more complicate when we look at OSM "relations" because they also add the same 10 interpretations for the list of its members, times the 10 interpretations for the members themselves (plus "roles" as well) ! And this applies to the "multipolygon" or to the "multilinestring" relations described here (even if roles are left uninterpreted ditinctively, something I doubt as multilinestrings have an "oriented" meaning by themselves independant of the orientation of members which do not necessarily connect each other), unless we further add restrictions of interpretation or validity constraints, exactly those that you have removed!

• OSM could also add a per-node boolean property (just like it could also add 1 dimension in the global measurement space to each node, such as altitude measured from the origin node or from the projection geoid, to go with 3D geocentric coordinates instead of just 2D polar geocentric coordinates, by changing or extending the arbitrary projection of orthogonal measurements) ; it would use the per-node boolean value to use them either as in-set nodes (the current default for all nodes), or as attraction "control" nodes, in order to use polynomial interpolations (e.g. Bezier curves, quadratic or cubic or with higher degrees) instead of just linear interpolations (straight segments). But this is not essential because polynomial interpolations are also dependant on the choice of the global measurement space (notably its arbitrary projection). If smoothed lines are desired, it is perfectly possible to infer additional control nodes between in-set nodes, using a basic interpolation between in-set nodes, based on fixed weighting parameters for this interpolation, just like we already remove nodes not representable on maps at a given scale (this is also an interpolation).

— Verdy_p ^(talk) 10:28, 4 December 2012 (UTC)

promoting multilinestring as new basic element

Just a personal note. It would be cool if the multilinestring would be promoted more like a new basic geometric element, not like a new type of relation (see Elements). Just like a multipolygon relation is a more complex geometric Area element, the multilinestring is a more complex Way element (either open or closed), which is used the same way as any other way-element, too. --Werner2101 15:33, 1 January 2013 (UTC)

+1. But that is allready the case, nothing forbids a contributor to use this relation in the place where he could use a way because that is exactly what it is made for. (Maybe you ment "more promoted" just like areas are often refered to ?). Note however that I think small/simple ways should still be modeled as way to avoid confusion and complexity (juste like simple areas are drawn by closed ways). sletuffe 16:06, 1 January 2013 (UTC)

Proposal

Why is this article page name not under proposals like Relations/Proposed/Collected Ways Simple? Also please add Template:Proposal_Page.--Jojo4u (talk) 16:58, 10 August 2015 (UTC)