Re: Line Segments without Streets are Streets?

Tom Carden wrote:

> I think it's worth mentioning here that "track" is a bad name for a
> collection of segments.  The term "track" is better for the raw GPS/GPX
> data we see in the editor.  I'd prefer "street" for now, and I'm open to
> something like "way" that Andy has been talking about if we want to
> represent other collections of segments.

FWIW, "path" seems reasonable to me.

-Alex Mauer "hawke"
--

-- 
Bad - You get pulled over for doing 90 in a school zone and you're drunk
off your ass again at three in the afternoon.
Worse - The cop is drunk too, and he's a mean drunk.
FUCK! - A mean drunk that's actually a swarm of semi-sentient
flesh-eating beetles.
OpenPGP key id: 0x51192FF2  <at>  subkeys.pgp.net

_______________________________________________
Openstreetmap-dev mailing list
Openstreetmap-dev <at> vr.ucl.ac.uk
http://bat.vr.ucl.ac.uk/cgi-bin/mailman/listinfo/openstreetmap-dev

Re: Re: OSM's Schema - moving it forwards.

On Wed, Nov 30, 2005 at 06:19:00PM +0100, Immanuel Scholz wrote:
> > In the mean time, my program that used CSV will have done the job, gone to
> > the pub and will be chatting up your bird.
> 
> For heavens sake, please! If you really want your CSV implemented, do it.
> I doubt that the XML converting part is the most complicated thing we
> currently have.

Wrong. Based on the amount of effort spent on the OSM mailing lists with
debating the intricacies of the data transmission format, it is the most
"complicated" issue. Or at least the most charged.

It's with this wasted effort that I am concerned.

> PS: I still don't see why this discussion has to be in osm and not in
> osm-dev mailing list... Maybe some lazy guy just always answer to osm
> mailing list? ;)

Yeah, true.

		Ben

Re: [Openstreetmap] Re: OSM's Schema - moving it forwards.

On Thu, Dec 01, 2005 at 12:25:10AM +0100, Tommy Persson wrote:
> And what is the problem with using well written and tested libraries?
> The code to parse it using the library is usually pretty trivial.
> 
> Where do you find these buggy XML-parsers?  I have not used them and
> the name of them could be good to know so I can avoid them.

Umm, they're neither well written nor particularly well tested. Take a
look at the bloat-tastic Xerces JAR, just as one example. I've suffered
through a number of projects using it as the data model parser, and we
had numerous problems. Maybe the newer versions are cleaned up, but it's
still almost a megabyte compiled. For just a parser. On a platform that
was originally all about lean web applications (remember Applets)?

> And to parse CSV data you usually have to read the manual.  I consider
> it to be a bug if data file are not resistent to extensions of the
> format.  How do you add new fields ina CSV format without breaking old
> files?

CSV parsing does not require a manual. It's in most good, standard
libraries (perl-CSV, csv.rb) and is simple enough to "just use." It
streams well -- line by line -- and works well when reading ahead of
time (ala' JDOM).

How do you add new fields to an XML data model, if it breaks every
version of the DTD / Schema out there? (Yeah yeah, it can be an optional
tag but that leaves different versions of the DTD / Schema floating
around.) What about the prevalence of crappy SAX event parsers that make
assumptions about tag order?

RE: OSM Schema discussions - Linear Map Features

Sent this to both mailing lists.

I'm slowly working through some logical map feature lists. It takes a while
to simplify it to core basics and I'm busy at the mo on other stuff so bear
with me. However since at the moment its "street, track, path, line, edge,
way etc" that's the flavour of the discussion, i.e. linear map features, I
thought I would at least share the current list of "ways" that I have in my
core list:

Definition of Way (Concise Oxford Dictionary):
way 1. n road, track, path (lit. or fig.) providing for passage along; place
of passage through door etc,; (in pl.) structure of timber etc. down which
new ship is slid when launched, parallel rails etc. as track movement of
machine; (as name of road or street, ancient: Appian Way, Icknield Way, or
modern)......

Suggested list of <way>'s including other linear map features for OSM:

RoadWAY	ie Suitable for vehicles	Includes MotorWAY/HighWAY/TrackWAY 
CycleWAY	ie Cycle routes	
BridleWAY	ie Suitable for horses		Might also include Canal
towpaths
FootWAY	ie Pedestrian ways		=PathWAY	
RailWAY	ie Ways with rails		Includes TramWAY and Monorails
WaterWAY	ie Navigable/non-navigable	Rivers and Canals
SeaWAY	ie Ferry and shipping routes	

Other linear features
911		ie Emergency routes		eg Fire access routes
Overhead	eg Cable cars, ski lifts and power lines (something bolted

Re: OSM's Schema - moving it forwards.

Hi,

>> I doubt that the XML converting part is the most complicated thing we
>> currently have.
>
> Wrong. Based on the amount of effort spent on the OSM mailing lists with
> debating the intricacies of the data transmission format, it is the most
> "complicated" issue. Or at least the most charged.
>
> It's with this wasted effort that I am concerned.

Well, I like to differentiate between "defining the data structure" and
"defining the transport format".

I only used the "transport format" XML to express my ideas about how the
data should be structured. I did it because I already know XML while I do
not know CSV or any other transport format as well.

My suggestion schema was the idea of reference data objects by id and send
it as a list rather than a hirachical tree where every data object contain
the full data of all childs, even if that mean to double data (as in GPX).

GPX send data by sending tracks which fully contain segments which in turn
contain points:

<trk><trkseg><trkpt lat=10 lon=20/></trkseg></trk>
<trk><trkseg><trkpt lat=10 lon=20/></trkseg></trk>

Both tracks contain the same point but both need to repeat the
information, which means data doubled and it is not clear whether there

Re: Re: [Openstreetmap-dev] OSM's Schema - moving it forwards.

On Wed, Nov 30, 2005 at 05:48:28PM +0100, Lars Aronsson wrote:
> Ben Gimpert wrote:
> 
> > You could preach to me about layers of abstraction atop the data 
> > model, but in reality "column-y" data models tend to trickle up 
> > through the whole set of application layers.
> > 
> > So should we get rid of RDBMS systems for something else?
> 
> To whom are you asking these questions?  Apparently, not to me.  
> You seem angry, but who is your enemy?  Anybody on this list?

Now see, I was totally gonna stop ranting. But this is specific to me:

I'm asking those questions both rhetorically -- as a writing device --
and generally to the OSM development community, who should be thinking
outside of the box for a project as edgy as OSM. If I seem angry, maybe
it's because I am -- a little. Mostly I'm just weary of people wasting
effort on data format wanking.

I've lurked on this list for a long time, but I chose to speak up during
the most recent in a long tradition of OSM data format threads. Not
because I want to convert everything to CSV or Illustrator, but to point
out the *FUTILITY* of the discussion! There are other GIS-community
mailing lists that have almost been rendered impotent by the amount of
standard wanking (ahem), and I hope it doesn't happen here.

To those who spend effort -- writing messages, designing specs, tweaking
the wiki, coding -- on defining the intricacies of the OSM data
interface: I plead of you, think about writing code. Or learning to

Re: database creation script

Immanuel Scholz wrote:
> Hi again,
>
> I'd like to setup a test server on my machine at home to do some little
> ruby tweaking.
> So... where is the script to setup the database? :) Nothing in SVN?
>
>
>   

One step ahead of you... see ticket 85 :)

Tom.

database creation script

Hi again,

I'd like to setup a test server on my machine at home to do some little
ruby tweaking.
So... where is the script to setup the database? :) Nothing in SVN?

Ciao, Imi.

PS: Anything else to remember when setting up an own server?

Re: OSM's Schema - moving it forwards.

Immanuel Scholz wrote:
> My suggestion schema was the idea of reference data objects by id and send
> it as a list rather than a hirachical tree where every data object contain
> the full data of all childs, even if that mean to double data (as in GPX).
>   

Imi,

Your draft schema has been around weeks/months.  We're not arguing about 
that, it was very useful (though there _are_ things that still need 
discussion).  We're arguing about starting yet another discussion about 
formats, and in a different place.  When *you* started to discuss it, it 
was because the current format was inadequate, and it was totally 
appropriate. But I don't see that problem now, which is why I so quickly 
had issues with Andy's proposal.

Ben's already covered the reasons why we chose to rant about XML, and 
he's right.

Please, again, if you care about this stuff, take it to the wiki... and 
don't be afraid to put half-baked thoughts on the wiki - that's what 
it's for!

Best,

Tom.

Re: OSM's Schema - moving it forwards.

On Thu, Dec 01, 2005 at 11:53:37AM +0100, Immanuel Scholz wrote:
> This is inefficient and not the idea of OSM data storage, where segments
> and points should be reused and combined to other objects if necessary.

It might be okay, we'll just gzip the redundancy away.

> Now, if you disagree that XML fits as a transport format, we can discuss
> another transport format. Make a concrete suggestion of the CSV structure,
> write some ruby and maybe point out a java library for CSV and we can try
> it out.

Nah, XML is fine. Or CSV. Or whatever. Let's just do it, and see if it
works in hindsight.

> But it could be wise to first profile some performance measurements on the
> server and applet since I still bet that the XML part is not the problem.

Very good idea. Maybe I'll look into how much CPU time (%) the Ruby
server stuff spends in the XML parsing.

		Ben