<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /></head><body style='font-size: 10pt; font-family: Verdana,Geneva,sans-serif'>

<p>On 2020-05-12 14:06, Frederik Ramm wrote:</p>

<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">

<div class="pre" style="margin: 0; padding: 0; font-family: monospace">Colin,<br /><br /> you're lumping in a few different things together I think.<br /><br /> The scarce resource in this project are still mappers, not consumers.<br /> The mappers certainly want to make a good and usable map; but if you are<br /> faced with a choice of either making mapping more difficult or making<br /> using more difficult, I would still argue for ease of mapping any time -<br /> especially as, for reasons of diversity, we're trying to extend the<br /> "long tail" of mappers who might not be willing and able to learn the<br /> ins and outs of public transport relation mapping.<br /><br /> So yes, let's give mappers the tools they need and let us have a<br /> dialogue with users about what they find useful, but if anything the<br /> users want means more complexity for mappers, I'm skeptical.</div>

<div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>

</blockquote>

<div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>

<div class="pre" style="margin: 0; padding: 0; font-family: monospace">Thanks for the reply Frederik. It can't be impossible to have a well-engineered internal setup, combined with a user-friendly external interface. I.e., do the Right Thing in terms of data structures, tagging models etc etc and present that to the user (through editors, primarily) in a user-friendly way. I know it can be done, I have been doing just that for 30 years.</div>

<div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>

<div class="pre" style="margin: 0; padding: 0; font-family: monospace">But it does require a level of meta-modelling. Real-world objects (recognisable to mappers) need to be mapped onto internal concepts. At present we have only nodes, ways and relations. Let's expand that upwards to include simple polygons, complex polygons, fuzzy areas, polylines etc (curved lines anyone?) Multipolygons and their alter ego boundary relations are a step in the right direction, but why is a boundary relation not simply defined as a "subclass" of a multipolygon for example?</div>

<div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>

<div class="pre" style="margin: 0; padding: 0; font-family: monospace">And then a layer of high-level "constraints" such as coastline needing to go anticlockwise. Is a relation an ordered list or not? The documentation says it is, but why dp editors not make it very easy to sort/re-order the members, or do it automatically?

<div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>

</div>

<div class="pre" style="margin: 0; padding: 0; font-family: monospace">Next level would involve tagging: for each object type, which fields are mandatory, recommended, optional, prohibited? What about regional applicability? What is mandatory in one place may be optional somewhere else.</div>

<div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>

<div class="pre" style="margin: 0; padding: 0; font-family: monospace">Editors can be coded to know about the metamodel, and then the constraints; a config file (JSON, XML, whatever) can provide the tagging schemas for the individual object classes. So we are not accused of imposing stuff from above: let's merge in an unmanaged config file on top of that so users can have their pet tags.</div>

<div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>

<div class="pre" style="margin: 0; padding: 0; font-family: monospace">As you and many others frequently remind us: OSM is first and foremost about the data and not any specific use-case or rendering thereof. We should take care to follow our own advice and nurture the data (quality), while at the same time not being afraid to revisit the data model and/or underlying metamodel.</div>

<div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>

<div class="pre" style="margin: 0; padding: 0; font-family: monospace">The community model of peers, with (by design) no real governance, has led to a lot of frustration, wheelspin and stagnation when it comes to making real progress on many fronts. We need to work on defining what we mean by "data quality", making it objectively measurable (if you can't measure it, you can't manage it), and taking steps to improve it. But any definition of quality depends on articulating what is good/right/expected vs bad/wrong/unexpected, and this is where we are far too timid!</div>

<div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>

</body></html>