Track data point editing:<br>If, as you say, the bad data is easy for me to see and not easy for software to<br>see then that would be a good reason for letting me edit the data. I think<br>we agree on that.<br><br>Markup:
<br>I should have been clearer. The project needs to have generalized<br>markup that is separate from the specific<br>rendering markup.<br><br>For small amounts of data with short life spans this extra step<br>looks like extra work and probably is, but for something large
<br>and long lasting, like mapping data, this extra step saves work.<br><br>For example HTML is considered to be a poor implementation of SGML because<br>it says how the data should be rendered instead of what the data is.
<br><br>Even if the rendering markup is still created by humans there are<br>advantages to having a generalized markup layer. One advantage,<br>but not the only one, is that in the future the rendering markup can be created
<br>by software.<br><br>Am I seeing a problem that no one else sees? Maybe, but the creators of<br>SGML saw this problem in other contexts long ago, and the recent<br>discussions I've seen on the mailing lists and things I've seen on the wiki
<br>indicate that OSM is having a problem with people<br>creating the rendering markup without generalized markup to guide them.<br><br>Layers: I'm not pushing for the layer thing to address this generalized<br>markup issue I brought up. It might be a good way to share notes and
<br>waypoints with other users though.<br><br><div><span class="gmail_quote">On 8/12/07, <b class="gmail_sendername">Tom Hughes</b> <<a href="mailto:email@example.com">firstname.lastname@example.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
In message <<a href="mailto:email@example.com">firstname.lastname@example.org</a>><br> "Jeffrey Martin" <<a href="mailto:email@example.com">
firstname.lastname@example.org</a>> wrote:<br><br>> Bogus points:<br>> How do we know which points we can throw away? I remember<br>> a similar question in my Analytical Chemistry class. I don't<br>> think the professor ever gave us a good answer but some
<br>> data just looks wrong.<br>><br>> My first day with the GPS I had two sets of bogus points.<br>> There's a big bunch that are too far apart to see a path.<br>> Maybe I had the sample rate set too low or maybe being
<br>> at my desk and getting signals through the window messed<br>> it up.<br>><br>> Later there was a rainstorm and<br>> I took shelter in the doorway of the grocery store. I could see the<br>> location walk all over the screen while I was standing still. Someone
<br>> else said he routinely takes off the first points collected before<br>> the GPS has settled down using a text editor.<br><br>I'm not saying that you don't get such things, or that they aren't<br>obvious to a human, but they're not always very easy to detect
<br>programatically.<br><br>In theory such points should have a high HDOP (horizontal dilution<br>of precision) value, but in my experience that is not always the<br>case, and that assumes that your GPS receiver logs the HDOP values.
<br><br>> Lines for tracks:<br>> I was converting the gpx files to osm files in JOSM to get something<br>> I could edit. This also give me arrows, but JOSM warns me that<br>> I shouldn't upload them to the server. That was a way I found doing
<br>> a google search. There may be a better way. I wish I could select<br>> points in order. The straight line selection almost does this. I guess<br>> what I want is a curved line selection.<br><br>Converting GPX files to OSM like that is generally frowned upon as
<br>it gives your far more points that you need normally (hence the<br>warning that JOSM gives you when you do it).<br><br>The preferred method is simply to create nodes by hand - it really<br>doesn't take any longer than converting to OSM and then removing
<br>the 90% of nodes that you don't really need.<br><br>> Layers:<br>> I noticed that having layers is a new feature in JOSM. I suppose<br>> having layers on the server is probably the most obvious way<br>> to do what I'm talking about, but there might be other ways.
<br>> Filtering based on an attribute?<br><br>Layers are not a new feature - local GPX files have always been in<br>separate layers, as have GPS points downloaded from the server. The<br>only new thing is having multiple layers of OSM data.
<br><br>> Notes:<br>> I don't take meticulous notes, but if I were to put my notes<br>> into the database when I get home I would probably add<br>> more detail.<br><br>Will that really be any quicker then just drawing stuff up properly
<br>though? I think most of our experience shows that<br><br>> Data standards:<br>> Years ago before HTML really took off I read up on SGML. The basic<br>> idea is that you separate the markup from the information.
<br>><br>> From what I understand of the process you design the structure<br>> of the data in the document and then maybe a week later or<br>> 30 years later someone writes software to deal with the data.<br><br>
That is precisely the separation we already have - the data in the<br>database is the raw data, and the map renderings are the markup.<br><br>> If I start to standardize my notes then that would increase<br>> accuracy. For example I could label two points bridge beginning
<br>> and bridge end, and then add attributes like bridge type, bridge subtype,<br>> number of lanes etc. A person could use this information to draw the<br>> bridge but later maybe software could.<br><br>If you're going to go to all that trouble to add standard labels
<br>to the nodes you might as well just draw the bridge - it will be<br>just quick as adding all those special tags to the endpoints!<br><br>Seriously how long can it take to draw one segment (most bridges<br>are straight after all) and make it into a way and add a couple of
<br>tags to the way? Will that really take much longer than adding a<br>couple of tags to each endpoint?<br><br>> Layers on the server:<br>> For a first step how do I get support for layers added to the server?<br><br>
Write the code, but I very much doubt it would be accepted as it<br>doesn't seem to be something for which there is much demand (you<br>are the only person that has ever asked for it as far as I know).<br><br>I think you are getting ahead of yourself a bit - you have encountered
<br>what you consider to be a problem, and constructed something you see<br>as a solution and are now pushing for that to be implemented.<br><br>I prefer to go back to the root problem and try to understand that<br>so that the community as a whole can derive a solution rather than
<br>assuming that your first stab at a solution is the right one.<br><br>Tom<br><br>--<br>Tom Hughes (<a href="mailto:email@example.com">firstname.lastname@example.org</a>)<br><a href="http://www.compton.nu/">http://www.compton.nu/</a><br><br>
_______________________________________________<br>talk mailing list<br><a href="mailto:email@example.com">firstname.lastname@example.org</a><br><a href="http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk">http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
</a><br></blockquote></div><br><br clear="all"><br>-- <br><a href="http://bowlad.com">http://bowlad.com</a>