[OSM-talk] cooperative mapping

Tom Hughes tom at compton.nu
Sun Aug 12 16:47:19 BST 2007

In message <bf60a2e10708120721g28c5ba6eveb5145e9abf05886 at mail.gmail.com>
          "Jeffrey Martin" <dogshed at gmail.com> wrote:

> Track data point editing:
> If, as you say,  the bad data is easy for me to see and not easy for
> software to
> see then that would be a good reason for letting me edit the data. I think
> we agree on that.

So you'd like to be able to edit GPS points in josm then, and delete
ones you think are wrong. You would probably also like to have GPS upload
integrated into josm (a common request I think).

> Markup:
> I should have been clearer. The project needs to have generalized
> markup that is separate from the specific
> rendering markup.

With a few exceptions (which I tend to dislike) we don't have rendering

A tag of bridge=yes means "this is a bridge". It says nothing about
how bridges will be rendered by any given map, or even if they will
be rendered at all - you could perfectly well make a renderer that
drew anything with bridge=yes as a row of pink teddy bears.

The few exceptions are things like osmaRender:nameDirection (or whatever
that tag is called) and as I've said I disagree with those.

> For small amounts of data with short life spans this extra step
> looks like extra work and probably is, but for something large
> and long lasting, like mapping data, this extra step saves work.

> For example HTML is considered to be a poor implementation of SGML because
> it says how the data should be rendered instead of what the data is.

Exactly. Which is why we generally don't do that.

> Even if the rendering markup is still created by humans there are
> advantages to having a generalized markup layer. One advantage,
> but not the only one, is that in the future the rendering markup can be
> created
> by software.
> Am I seeing a problem that no one else sees? Maybe, but the creators of
> SGML saw this problem in other contexts long ago, and the recent
> discussions I've seen on the mailing lists and things I've seen on the wiki
> indicate that OSM is having a problem with people
> creating the rendering markup without generalized markup to guide them.

I think the problem is that nobody else understands what you think
is renderer specific about our tags. Our tags are designed to record
the physical reality of the things the things we map, and it is up
to users of the database (mostly map renderers at present) to decide
how to use that information (ie how to render things).

Perhaps you can give some examples of where you think our tags are
too HTML like and how you would make then more SGML like?

> Layers: I'm not pushing for the layer thing to address this generalized
> markup issue I brought up. It might be a good way to share notes and
> waypoints with other users though.

I don't disagree with sharing waypoints, but that wouldn't be done
by any generalised server side layering mechanism.

The obvious implementation is simply a gps_waypoints table on the
server to go with the existing gps_points table, and a API call to
fetch the waypoints like the existing one to fetch the GPS waypoints.

Josm would then be able to fetch those waypoints and display them in
a separate layer just like it does with GPS points.


Tom Hughes (tom at compton.nu)

More information about the talk mailing list