On 2020-05-12 14:06, Frederik Ramm wrote:
> Colin,
>
> you're lumping in a few different things together I think.
>
> The scarce resource in this project are still mappers, not consumers.
> The mappers certainly want to make a good and usable map; but if you are
> faced with a choice of either making mapping more difficult or making
> using more difficult, I would still argue for ease of mapping any time -
> especially as, for reasons of diversity, we're trying to extend the
> "long tail" of mappers who might not be willing and able to learn the
> ins and outs of public transport relation mapping.
>
> So yes, let's give mappers the tools they need and let us have a
> dialogue with users about what they find useful, but if anything the
> users want means more complexity for mappers, I'm skeptical.
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.
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?
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?
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.
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.
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.
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!
_______________________________________________
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
