On Mon, Dec 17, 2018 at 1:25 AM François Lacombe <fl.infosrese...@gmail.com> wrote:
> > I still think that actuator=* is better than two pipeline:valve:actuator=* > and railway:switch:actuator=* because the first is really more concise and > reusable between valves and railway switches. > Like I don't like fire_hydrant:position instead of simpler location=*. > > Can someone brings benefits from using namespaces in this particular > situation please? > There is a benefit to the authors of editors such as iD and JOSM when the set of values for the two different use cases is not identical. So if valve actuators take the values A, B, and C, whilst railway actuators take the values A, X, and Y, this causes code complexity. The reason is that a key like pipeline:valve:actuator can be handled as a list of values A, B, C and a key like railway:switch:actuator can be handled as a list of values A, X and Y. But if it's just actuator=* for both then the editor needs extra code to present whichever values are valid for the appropriate primary key. It's not much for any one key, but it starts to add up when there are several keys like that. Alternatively the editor just presents a list of A, B, C, X and Y in both cases and then people end up accidentally using values that are inappropriate simply because they're in the list. Even if the values are of one are a subset of the other, it means that extra code is needed to distinguish between the two primary keys to decide whether to present a limited list or a full list of values. Throw in potential complications with associated keys that may differ between the two types of actuator (do railway actuators have "turn to open"?) then the code can get messy. This isn't theoretical speculation. The author of iD has, in the past, expressed unhappiness about such re-usability. I'd also guess that such re-use also causes similar problems on the carto side if, for example, railway actuators get different rendering from pipeline actuators. Although my first instinct would be to minimize the number of keys in the database that turns out to be a premature optimization. -- Paul
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
