I saw your edit to Computing access restrictions. I wrote the original page and I don't agree with the transport mode hierarchy being a graph instead of a tree: if it's a graph, the algorithm described in that page does not work any more! I had already added such a comment to the discussion tab. --User:FedericoCozzi 08:53, 12 March 2009 (UTC)
- IMO, this is a non-issue. I've updated the page with some comments and thoughs on the algorithm. I note it's a DAG with a single root, so just update the algorithm description with a search back to that root. If you want the simple algorithm instead, you can just partition by whether the way is a waterway or a highway. --achadwick 12:07, 12 March 2009 (UTC)
- Please, could you move that long discussion to the discussion tab? I do understand that you could visit the whole DAG, but returning the full choices to the user is not possible: if this algorithm is run within a route-searching algorithm, you can't ask the user for all the backtracking options! Moreover, if you relax the constraint that transport modes are a tree and allow DAGs instead, on the other hand you must restrict the constraint on the access mode tags themselves which can't be unstructured anymore but need either a total order or a lattice structure on them. That is, if you are more permissive with the transport mode tags (allowing DAGs instead of trees) then you must be more restrictive on the access mode tags (my imposing extra structure on them). I think this trade-off is bad: it is much easier to impose the tree condition on transport mode tags than imposing the lattice condition on access mode tags. Look at it this way: the only problem in your example is a motorboat which inherits both from boat and from motor_vehicle. But this second inheritance is useless: no waterway will ever be tagged as motor_vehicle=no, as the only motor_vehicle which inherits from boat is a motorboat. Therefore you can easily tag this waterway as boat=yes, motorboat=no which means exactly the same as boat=yes, motor_vehicle=no. Therefore I still think that the tree condition on transport mode tags is not excessively restrictive.
Proposed features/left name)
I see that you moved this proposal to "rejected" after someone else moved that to "inactive". But what is your proposal for this kind of problem where two sides of a street have a different name ? "inactive" does not mean "abandonned" and it does not mean "rejected". Rejected by who ? -- Pieren 22:23, 24 May 2009 (UTC)
- I both marked Rejected_features/left_name as inactive - since it was - and moved the page. Nobody had moved it to inactive; I marked it as inactive. My favoured proposal is Proposed features/right left. Please read Proposed features#Rejected: inactivity does indeed mean abandonment, and a good thing too. Rejected by OSMers generally, due to lack of interest (what with the 3 month inactive history). Feel free to revitalise the proposal and try to gain more interest for it. --achadwick 00:32, 31 May 2009 (UTC)