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:

<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

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.

<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:tom@compton.nu">tom@compton.nu</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:bf60a2e10708120458o6265a3e3mfa219214a1f82a84@mail.gmail.com">bf60a2e10708120458o6265a3e3mfa219214a1f82a84@mail.gmail.com</a>><br>          "Jeffrey Martin" <<a href="mailto:dogshed@gmail.com">

dogshed@gmail.com</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

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.

<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

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.

<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

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.

<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:tom@compton.nu">tom@compton.nu</a>)<br><a href="http://www.compton.nu/">http://www.compton.nu/</a><br><br>

_______________________________________________<br>talk mailing list<br><a href="mailto:talk@openstreetmap.org">talk@openstreetmap.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>