[Tagging] Proposal for a generic : type=multilinestring

sly (sylvain letuffe) liste at letuffe.org
Thu Jan 26 15:02:42 GMT 2012


On jeudi 26 janvier 2012, LM_1 wrote:
> In the proposal it says:
>  "If you have one way making up the line string ring and it does not
> describe something in its own right, you may also put these tags on
> the relation and leave the relation untagged." - that does not really
> make sense to create such relation (one way tagged relation would make
> splitting the way easier).

Oups, looks like a copy paste error, there are no reasons to have rings for 
those relations and instead of "relation" read "way" for the 2nd relation, 
I'm changing it in the wiki.

 
> "The order of the relation members does not matter (but properly
> sorted member lists can help human editors to verify completeness)." -
> I believe it should be always sorted, yet routers/renderers should not
> rely on it.

Well, I'd say "it's better if" but since it will not always be the case, data 
consumers should not rely on it.
A API server side re-ordering whould be cool, but that's not part of the 
proposal

> How would it be used in this situation?: border of two countries (A,
> B) is also border of lower administrative divisions (AC, AD in country
> A and BE,BF in country B). going along the border you go through
> different combinations (A-B all the way; AC-BE->AD-BE->AD-BF; see
> image). In reality there would be more than two levels and therefore
> much more combinations.

Either you keep this model for the higher admin entity (country) like it is 
used now sometimes with type=boundary_segment, or, at your option, or your 
local community's, goes as deep as you want. That's also why this 
proposition, unlike the type=multipolygon one, expressly states that it can 
be used recurrently with other type=multilinestring as members

> How would it solve the case of river bifurcation if the river merges
> together (river island, the same river flows on both sides)?

It will not.
However, it can be used for the main line river, wich, in turn, could be 
member of a type=river relation.
I designed type=multilinestring as a geometry model, not as a fancy 
ever-changing relation with roles or nodes. It can be used as being the 
member of other complex relation grouping several features, but building it's 
geometry is meant to be as stable in time as possible.

> How would it solve similar case of streets (lanes for different
> directions split for some time and later merge together)?

Same, it will not. 


-- 
sly
qui suis-je : http://sly.letuffe.org
email perso : sylvain chez letuffe un point org



More information about the Tagging mailing list