[OSM-talk] cooperative mapping

Jeffrey Martin dogshed at gmail.com
Sun Aug 12 15:21:48 BST 2007


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.

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

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.

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.

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.

On 8/12/07, Tom Hughes <tom at compton.nu> wrote:
>
> 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
> programatically.
>
> 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
>
> --
> Tom Hughes (tom at compton.nu)
> http://www.compton.nu/
>
> _______________________________________________
> talk mailing list
> talk at openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
>



-- 
http://bowlad.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20070812/2edcb334/attachment.html>


More information about the talk mailing list