[Tagging] RFC: Seaway key - proposal for mapping ports

stevea steveaOSM at softworkers.com
Sat Mar 6 12:16:11 UTC 2021


I’m surprised to see discussion like this.  Getting lost in the weeds about rudimentary graph theory (routes and vertices within them, fairly simple concepts about transitive reductions in directed acyclic graphs...) is being confused with a proposal about mapping ports and “seaways.”  So, there seems to be much confusion to undo already.  The “raw math” (graph theory) of whether a port is “intermediate or terminal” has nothing to do with ports (fishing, freight, passenger_ferry…) themselves, now, does it?  And “ports” (via Seaway) is the initial thrust of the proposal.  Left out of Seaway were routes (until I brought up that they might introduce and make things messy, so let’s draw a bright line about that…), yet here we are seemingly snarled in discussions about routes and components of and about them that have nothing at all to do with ports.  These are unrelated:  graph theory isn’t discussion about maritime / marine transport infrastructure.

Routes were not even mentioned (by Martin) until I suggested that because we have them in train and road networks, they seemed they would find their way into sea networks, too, and indeed already had by way of ferry routes (which the proposal “simply” points to, and likewise, it points back to the proposal).  So, let’s be aware of how routes do or don’t “fit with” marine transport / ports.  Step one:  we have ferry routes.  That wasn’t even addressed, it was “punted” with a link to “how that’s done."

While I appreciate Martin’s point-by-point replies here, his phrase of “should be dealt with by people who know more about this topic” is what sticks in my mind — about the entire proposal.  We only seem to be at the first baby steps of this and we’re already off to what looks like a confused start talking about routes, which seem tangential (though likely aren’t) to the basics of defining a scope, which has yet to be done here.

Finally, Martin states "because making a complete, differentiated scheme in one go would probably have led to something too complicated to digest in a single proposal.”   This should give the author pause.  If what is led to is too complicated to digest in a single proposal, it isn’t worthy of consideration, is it?  I have authored or co-authored at least one proposal so tediously complex it took weeks — months — of collaboration resulting in such drastic simplification (but not over-simplification) that it hardly resembled the original proposal.  But what made it worthy is how it “semantically flattened" both real world semantics and one simple example of existing tagging into an equivalence.  Such fortunate (and amazing in their sense and simplicity) outcomes aren’t always possible while developing tagging proposals, but they do show what actually developing a proposal can do, rather than holding out a loose bucket and asking it to be filled with unfocused ideas.

I remain in listening mode about Seaway, but now it needs not only depth (agreed to by Martin) but serious focus and scoping as well.  I wish I knew how to help with more specificity, Martin, really, I do.


More information about the Tagging mailing list