<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Ben Laenen wrote:
<blockquote cite="mid:200905221219.07538.benlaenen@gmail.com"
 type="cite">
  <pre wrap="">On Friday 22 May 2009, Andy Allan wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">On Thu, May 21, 2009 at 6:13 PM, Ben Laenen <a class="moz-txt-link-rfc2396E" href="mailto:benlaenen@gmail.com"><benlaenen@gmail.com></a> 
    </pre>
  </blockquote>
  <pre wrap=""><!---->wrote:
  </pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">A typical city here would look like all roads inside the built-up
area inside one relation, and when there are roads inside it with
another speed limit, tag those ways with maxspeed.
      </pre>
    </blockquote>
    <pre wrap="">Jesus.

* Anyone who doesn't know what ST_Intersects means should go find
out. And I mean by writing an application, not by using google
* Anyone who thinks that processing relations is magically wonderful
should go reimplement the translucent colouring on the cyclemap
without any overlap artifacts.
* Anyone who thinks that "GIS Stuff" is too complex for portable
devices should think long and carefully about the word
"pre-processing" and c.f. osm2pgsql, mkgmap, XAPI and every other
tool we have for that already. Oh, and write an application that uses
them, not just read the wiki.

This has to be one of the absolute worst discussions for people
asserting things they actually have no experience of doing. It's
cringe-worthily painful to read.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Not sure what your comment is doing here. We're trying to get 
information about ways into OSM in the first place here, so for example 
the map in you gps map knows after preprocessing the OSM data how fast 
you can go on each road. So this is a discussion about how to store 
that data so it is not too difficult, can be easily maintained in 
future and doesn't have obvious flaws.

So what your rendering stuff is doing here, no idea. We're not trying to 
render anything here.

Ben


  </pre>
</blockquote>
For years and years of my professional career I had to listen to the
stuff people (my customers) spouted about gathering data yet then had
absolutely no real idea of how it would be used.  That was some magic
computers worked.  Processing the data (of which rendering forms a 
part) is an essential consideration *before* you start storing it. 
Andy's real-world points are a breath of fresh air in this otherwise
rather pointless thread.<br>
<br>
Cheers, Chris<br>
</body>
</html>