[OSM-talk] cooperative mapping

Tom Hughes tom at compton.nu
Sun Aug 12 13:53:54 BST 2007

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

> Bogus points:
> How do we know which points we can throw away? I remember
> a similar question in my Analytical Chemistry class. I don't
> think the professor ever gave us a good answer but some
> data just looks wrong.
> My first day with the GPS I had two sets of bogus points.
> There's a big bunch that are too far apart to see a path.
> Maybe I had the sample rate set too low or maybe being
> at my desk and getting signals through the window messed
> it up.
> Later there was a rainstorm and
> I took shelter in the doorway of the grocery store. I could see the
> location walk all over the screen while I was standing still. Someone
> else said he routinely takes off the first points collected before
> the GPS has settled down using a text editor.

I'm not saying that you don't get such things, or that they aren't
obvious to a human, but they're not always very easy to detect

In theory such points should have a high HDOP (horizontal dilution
of precision) value, but in my experience that is not always the
case, and that assumes that your GPS receiver logs the HDOP values.

> Lines for tracks:
> I was converting the gpx files to osm files in JOSM to get something
> I could edit. This also give me arrows, but JOSM warns me that
> I shouldn't upload them to the server. That was a way I found doing
> a google search. There may be a better way. I wish I could select
> points in order. The straight line selection almost does this. I guess
> what I want is a curved line selection.

Converting GPX files to OSM like that is generally frowned upon as
it gives your far more points that you need normally (hence the
warning that JOSM gives you when you do it).

The preferred method is simply to create nodes by hand - it really
doesn't take any longer than converting to OSM and then removing
the 90% of nodes that you don't really need.

> Layers:
> I noticed that having layers is a new feature in JOSM. I suppose
> having layers on the server is probably the most obvious way
> to do what I'm talking about, but there might be other ways.
> Filtering based on an attribute?

Layers are not a new feature - local GPX files have always been in
separate layers, as have GPS points downloaded from the server. The
only new thing is having multiple layers of OSM data.

> Notes:
> I don't take meticulous notes, but if I were to put my notes
> into the database when I get home I would probably add
> more detail.

Will that really be any quicker then just drawing stuff up properly
though? I think most of our experience shows that

> Data standards:
> Years ago before HTML really took off I read up on SGML. The basic
> idea is that you separate the markup from the information.
> From what I understand of the process you design the structure
> of the data in the document and then maybe a week later or
> 30 years later someone writes software to deal with the data.

That is precisely the separation we already have - the data in the
database is the raw data, and the map renderings are the markup.

> If I start to standardize my notes then that would increase
> accuracy. For example I could label two points bridge beginning
> and bridge end, and then add attributes like bridge type, bridge subtype,
> number of lanes etc. A person could use this information to draw the
> bridge but later maybe software could.

If you're going to go to all that trouble to add standard labels
to the nodes you might as well just draw the bridge - it will be
just quick as adding all those special tags to the endpoints!

Seriously how long can it take to draw one segment (most bridges
are straight after all) and make it into a way and add a couple of
tags to the way? Will that really take much longer than adding a
couple of tags to each endpoint?

> Layers on the server:
> For a first step how do I get support for layers added to the server?

Write the code, but I very much doubt it would be accepted as it
doesn't seem to be something for which there is much demand (you
are the only person that has ever asked for it as far as I know).

I think you are getting ahead of yourself a bit - you have encountered
what you consider to be a problem, and constructed something you see
as a solution and are now pushing for that to be implemented.

I prefer to go back to the root problem and try to understand that
so that the community as a whole can derive a solution rather than
assuming that your first stab at a solution is the right one.


Tom Hughes (tom at compton.nu)

More information about the talk mailing list