[OSM-talk] Looking Forward

[ce-test, qualified testing bv - Gert Gremmen]

Frederick showed us some of the  problems of OSM itself (well done !),
pragmatic problems needing to be solved for OSM to survive, but once
solved do not change fundamentally change anything to OSM.
That is ok if OSM is perfect for the next 100 years or so, but
that will not be the case I believe.


Currently the ultimate goal anyone seems to pursue is data completion.
But, once every road and POI has been mapped, were done.
There is no structured vision yet upon what to do with that data.

We did not even develop a structured view on how we will be updating that
immense dataset.

What can and will the world do with OSM ?

Of course there is the dogma of allowing new and surprising
applications that would be possible with "open and free" data.
Such new applications have yet to be developed; most applications
made up to now are of a trivial level (where is my friend drinking), 
direct but inferior copies of commercial applications (route planners), 
or directed to the community itself (editors). No surprise app
that I heard of.  
That is not surprise, we are currently just trying to get even with
the BIG boys, copying their achievements with only one
difference: our data is "free".

In order to become a real innovative map, we need to provide
innovative data (or means to extract it) ,not just "free" data. 

Some ideas to create real innovative value:

A/ History
One of the first things that get into my mind is history.
Being able to show how the world was yesterday is something
no map maker ever made available on a simple and real time basis.
Of course OSM has not much of a history yet, but that will hopefully
change, and work need to be done
It will allow anyone to provide data on how this world progresses
be it agricultural, nature areas, road density or café's per square mile,
these data change, and it would be good if we had the tools to use that history.

B/ Third world 
A second important thing will be to provide information to the third world,
countries where a simple paper map is simply not available, or outdated
or lists only those things that are politically correct. OSM, as
a user generated map, is able to make itself free from that limitations
and should innovate the way poor countries use maps.
HOT is one step into that direction, but by its nature triggered
by disasters is always lagging the need for data. Can OSM
provide means to those countries to get a grip on their own geo-data
and how ?

C/ Political
Maps are a view of the world seen from (most of the time) the western
hegemony on the world. Names of cities areas and countries and frontiers 
are different and their spelling or geographic properties depend on
who you ask. By complying to our western view, we make a political choice;
a choice that will stand in the way of acceptance of our data.
Should we map Tibet as a country or as a part of China ? same for Taiwan.
Should we respect al kind of undefined local properties in Africa, and
what exact borders will their countries have. Examples in abundance if you
open your eyes for it.
I believe that we should allow our data users to extract the data complying
to their view of the world, within the view as defined by our mappers of
course. No need to seek for hidden border disputes of course.
That means that Tibet will be include as a part of China if rendered
within a China view , or as a independent country if rendered by
the dalai lama. It is not to us to comply with 1 (one) view of the world.

D/ Details
Apart from mapping conventions, and tagging styles (fixed of free),
how far should OSM go into detailing the world. Map resolution is currently 
defined by the resolution of GPS and partly because of mapping conventions, but
with new GPS systems developing with sub-meter accuracy, should we allow
or mappers to map sub-meter details ?? It is possible now (in JOSM),
but do we desire so ? Will there be a need for even smaller points of interest,
and could that lead to mapping innovation ?


My 4 cents...


Gert




-----Oorspronkelijk bericht-----
Van: Frederik Ramm [mailto:frederik at remote.org] 
Verzonden: zaterdag 24 december 2011 14:03
Aan: talk at openstreetmap.org
Onderwerp: [OSM-talk] Looking Forward

Fellow OSMers, 

   I'd like to use the calm end-of-year season to say a few things I
consider important, hoping that I might get a few people to spend a
thought or two on them.

I've been accused in the past of not having a vision for OSM and I
don't claim to. But it would be great if those who have a vision would
also have answers to the issues I want to talk about.

Our admins have recently published a list of "top ten tasks",
technical things they'd like to see implemented sooner rather than
later. Looking at that list makes you think: If *those* are the biggest
problems then the project must be working quite well! But fact
nobody claims that they are the biggest problems: they are just the
lowest hanging fruits. 

The OSMF is very much concerned about making sure that user experience
is improved and that it becomes easier for everybody to contribute to
OSM, shedding our image of being a project for geeks and enthusiasts,
and I've heavily contested that on osmf-talk. The underlying idea seems
to be that of any web startup: Once we achieve growth everything else
will fall into place. And who's to blame them - it has worked for OSM
for quite a while. Indeed among the more technical-minded people in OSM
the making of big plans is usually frowned upon as "astronautism". (To
be fair, a project as big as OSM does indeed attract a fair number of
people who think that even without knowing anything about OSM, they can
surely tell us that we should use a certain trendy technology to
continue to work.)

All this together means that everybody - including myself - is more or
less sticking their heads in the sand when it comes to the real big
issues, issues for which we not only lack a solution, but where it is
even unclear how we could arrive at one and implement it.

(And I'm not even talking about the license change - that is, at least,
an issue where the path ahead is relatively clear and things just need
to get done.)

Here's my shortlist of "big issues" for our future:

1. Strict Tagging Rules

Not a week goes by without some discussion on a forum or mailing list
ending in a lament about the lack of strict tagging rules. Data users
hope to be able to find out that the feature they're looking for will,
if it exists, be tagged exactly so and so. Junior mappers want to know
how exactly to tag certain objects. Experienced mappers despair at
others changing their hard work according to some wiki "vote" that
attracted 15 participants out of tens of thousands.

The current wisdom is "we neither have nor want strict rules" - we have
got where we are now precisely because we did not waste time on trying
to come up with rules. Also, we are an international project with
diverse communities and there is no reason why everyone in the world
should tag the same. But still the issue remains, and a lot of valuable
time is wasted between mappers discussing the merits of one tagging
scheme or the other. Sometimes, edit wars ensue which then bind even
more resources in mediation.

Meanwhile, editor writers and bot programmers gain all the power - it
is, in effect, them who decide what gets tagged how (or auto-corrected
if the user should be so audacious as to use a tag differently).

This is a continuing source of friction. Our data is more valuable and
easier to use if it easy to interpret; mappers could often benefit from
that as well. But tagging freedom, and the lack of a "central tagging
command" structure, have brought us where we are. In contrast to other
systems like Google Map Maker, our mappers are not just worker ants
expected to mind-numbingly fill in the blanks on a form; they can be
creative agents deciding what gets mapped and how. Out of despair some
people even call for a "tagging czar" who would make a decision
whenever the community doesn't arrive at one. This doesn't look like a
good solution to me but it illustrates the problem.

The project changes, and the bold and autonomous mappers of the first
few years (who often had a whole city to themselves) are in decline; we
have more people who actually *want* to be told what to do. But with
many of the sensible people in our project being from that bold
generation and not wanting to create rules for others, we end up with
rules being made by people with strange ideas whose main spare time
activity seems to be rule-making rather than mapping, and voted on by
people who cannot grasp the consequences.

2. Imports and the Community

Governments all over the world are opening up their data. OpenStreetMap
was born from frustration: "You don't give us your data, ok, then we
collect it ourselves." - More and more, governments are giving out
their data, and many people less familiar with OSM's tradition of
surveying think that this must be a boon for the project and wildly
import any government data they can find.

The point has been made that imports damage a community, or even keep a
healthy community from forming in the first place. There already is
more free and open geodata in the world than we could ever deal with;
how can we make sure that OSM is not ruined by importing more than we
can digest?

A stock answer for the "I want to import XY into OSM" issue is "put it
in a separate database and merge when rendering" and this might indeed
be sensible for many areas, but it would require easier ways for
merging data and also ways to see these other data sets while editing;
but most of all we would have to get the message across that OSM is not
intended to be a "melting pot" of the world's geodata. 

3. Level of Detail, Relation Overload

Everyone who downloads OpenStreetMap data gets the same stuff, whether
they want it or not. This is especially true for people wanting to edit
OSM, but also for data users. You always get the full detail, down to
every last post box and garden shed. In the traditional GIS world this
is different; data is usually produced in several scales (see e.g.
naturalearthdata.com) or, where one master map exists, downscaled from
that using sophisticated algorithms or even manual work.

The only application in which we have something comparable is tiles -
of course no attempt is made to draw residential roads on zoom level
10. But other than that, everyone always has to deal with the full
amount of data we have. With ever-increasing depth of detail, the
"50,000 node" download limit for editing means that the area you can
download for editing becomes smaller and smaller, and even if you could
download more it would be hard to handle in the editor. 

OSM prides itself in not having Wikipedia's much-hated and hotly
debated "relevance criteria" - while we do sort of expect that you
don't enter data that you cannot maintain, we largely allow people to
add whatever data they are interested in. This has potential to cause
trouble especially when coupled with imports - recent discussion
revolved around 3D building data, about drawing roads as areas, about
historic information, or about certain streets meanwhile being a member
of 30-odd relations because there are that many bus lines. This is
despite the overwhelming majority of OSM contributors not being
interested in 3D buildings, historic data, or public transport
information. You can choose what to display on a map, but you cannot
choose when editing; the mapper always has to deal with the full depth
of information. There are limited options of "hiding" stuff in editors
but that only goes so far and carries the risk of breaking implied
spatial relationships.

We must find ways for people to deal with one topic to their heart's
content without impacting the work that others do; otherwise any work
we do to make editing simpler will be nullified by the sheer amount and
complexity of data.

4. Data Model Changes & Technology

Our data model is reasonably simple but it does have its quirks and it
begins to show. More than half of our ways are used to model areas
(which is mainly due to imported building data), yet we don't have a
proper area data type. This is being discussed but no solution is
apparent; API or data model changes used to be something that one could
simply decide at a hack weekend but with an ever increasing number of
users and data consumers it becomes more demanding. We manage to paper
over any cracks in our data model by using relations but they are
hopelessly under-specified and often hard to evaluate automatically
(witness e.g. discussions about using cascading relations for
boundaries). Relations often make editing difficult, and they sometimes
have several thousand members and several thousand historic versions
which makes them hard to handle in all respects. But simply ignoring
them or even dropping support for them becomes less and less of an
option.

Also, the way we distribute database updates - the daily, hourly,
minutely diffs - is optimized for keeping a fully replicated OSM
mirror, but less suitable for keeping regional extracts (as you always
download and process a world-wide diff and then discard most of it),
and practically unsuitable for keeping thematic extracts (because a tag
added to a way might suddenly make that way interesting for you but you
lack information about the nodes required).

                                 ----

Some people seem to assume that if only we grow big enough then all
these problems will solve themselves somehow. Maybe we can simply
outsource problem solving to paid coders from some web platform, or
OSMF could hire people and tell them to fix things somehow. But it
seems to me that while these problems may have a technical component,
they are very strongly linked to how we work in OSM - the mappers, the
technologists, the sysadmins, how everything goes together -, and
solving them requires a good way of decision making in the community. I
don't think that e.g. OSMF is the body that can or should be burdened
with that decision making; but I don't have an alternative either. We
like to say "show working code or STFU" but one has to be honest and
admit that once problems reach a certain complexity, that basically
boils down to being in denial about the problem.

I'd love to find that all the problems I listed here turned out to be
non-problems in the end, and were somehow solved automatically along
the way. It wouldn't be the first time for me to think something is a
problem and OSM took it in its stride. Maybe mentioning the issues
already helps to achieve that magic.

Merry Christmas, or whatever you're having -
Frederik


_______________________________________________
talk mailing list
talk at openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk