[OSM-talk] [Fwd: Re: cooperative mapping]

Ray Booysen raybooysen at rjb.za.net
Sun Aug 12 16:37:03 BST 2007


Forwarding to list.  This email was sent to my personal address.

-------- Original Message --------
Subject: 	Re: [OSM-talk] cooperative mapping
Date: 	Mon, 13 Aug 2007 00:35:07 +0900
From: 	Jeffrey Martin <dogshed at gmail.com>
To: 	Ray Booysen <raybooysen at rjb.za.net>
References: 
<bf60a2e10708112056r64a85737s1a963a7faf4e3119 at mail.gmail.com> 
<25c320114f.tom at loxley.compton.nu> 
<bf60a2e10708120458o6265a3e3mfa219214a1f82a84 at mail.gmail.com> 
<a08a36114f.tom at loxley.compton.nu> 
<bf60a2e10708120721g28c5ba6eveb5145e9abf05886 at mail.gmail.com> 
<46BF1C0A.2040705 at rjb.za.net>



Maybe the current OSM tagging scheme is partially general and partially 
rendering.
Maybe we can say it's somewhat general but not general enough.

It's been a few years since I read the book, and the book was mostly
about text documents, but if I apply the SGML philosophy to road maps
then there should be standard methods of describing things like roundabouts,
intersections, bridges and multilane highways. You would then use those
standard general descriptions to create the ways and segments.

For example if we come up with a general method for describing intersections
and we use that method to describe a particular intersection with a 
particular
arrangement of turn lanes then we will have that information as a 
generalization,
and then we can experiment with different methods of creating the ways and
segments to represent that intersection. There is even the option of 
replacing
the ways and segments now used with something else.

One advantage here is that if the segment and way representation needs to
be changed for some reason then the generalized data is available to use 
instead
of being on a piece of paper in a contributor's desk drawer.

-Jeff Martin

On 8/12/07, *Ray Booysen* < raybooysen at rjb.za.net 
<mailto:raybooysen at rjb.za.net>> wrote:

    Jeffrey Martin 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.
     >
     > Markup:
     > I should have been clearer. The project needs to have generalized
     > markup that is separate from the specific
     > rendering markup.
    Yes already happens.  The markup (tags, segments, ways) are all
    separate
    from the rendering.

     >
     > 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.
    Renderers can apply their own styles and can render tags how they want.
    There are no rules on how renderers must display the data.

     >
     > 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.
    Layers of what?



     >
     > On 8/12/07, *Tom Hughes* <tom at compton.nu <mailto:tom at compton.nu>
    <mailto:tom at compton.nu <mailto:tom at compton.nu>>> wrote:
     >
     >     In message
     >     < bf60a2e10708120458o6265a3e3mfa219214a1f82a84 at mail.gmail.com
    <mailto:bf60a2e10708120458o6265a3e3mfa219214a1f82a84 at mail.gmail.com>
     >     <mailto:
    bf60a2e10708120458o6265a3e3mfa219214a1f82a84 at mail.gmail.com
    <mailto:bf60a2e10708120458o6265a3e3mfa219214a1f82a84 at mail.gmail.com>>>
     >               "Jeffrey Martin" < dogshed at gmail.com
    <mailto:dogshed at gmail.com>
     >     <mailto: dogshed at gmail.com <mailto: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 <mailto:tom at compton.nu>
    <mailto:tom at compton.nu <mailto:tom at compton.nu>>)
     >     http://www.compton.nu/
     >
     >     _______________________________________________
     >     talk mailing list
     >     talk at openstreetmap.org <mailto:talk at openstreetmap.org>
    <mailto:talk at openstreetmap.org <mailto:talk at openstreetmap.org>>
     >     http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
     >     <http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk>
     >
     >
     >
     >
     > --
     > http://bowlad.com
     >
    ------------------------------------------------------------------------
     >
     > _______________________________________________
     > talk mailing list
     > talk at openstreetmap.org <mailto:talk at openstreetmap.org>
     > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
    <http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk>
     >


    _______________________________________________
    talk mailing list
    talk at openstreetmap.org <mailto:talk at openstreetmap.org>
    http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk




-- 
http://bowlad.com




More information about the talk mailing list