Wow, this is fantastic and very exciting! Stefan - by javascriptsockets were you thinking of the thru-flash technique for sockets? I'd love to help out if I can. Right now, Cartagen doesn't use sockets, but small Ajax requests every 1/3 of a second. Latency is low but not quite realtime... it's within about a second but depends on the size of the plot requested of course. I've been avoiding Flash because it's not available on the iPhone or Android, and it'd be nice to have almost the same renderer/editor codebase on mobile devices and PC.<div>
<br></div><div>Just curious, how does Mapnik or Omsarender do it? Surely they don't actually render every node of a way for very large bboxes?</div><div><br></div><div>Jeff<br><br></div><div><br><div class="gmail_quote">
On Wed, May 6, 2009 at 8:51 PM, Stefan de Konink <span dir="ltr"><<a href="mailto:stefan@konink.de">stefan@konink.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">Jeffrey Warren wrote:<br>
 > c) trying to serve partial polygons... I'd like to try plotting only<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
every 3rd or 10th node... do the polygons collapse? Can i cull nodes in a more intelligent way? Someone on this list or geowanking pointed to a company that can serve lower-res polys over an API. I'm sure folks have worked on this in tile systems, so if you know anything about it and are willing to share, I'm all ears. This becomes really relevant as you zoom out... don't want to render every node for the coast of Argentina, for example.<br>

</blockquote>
<br></div>
I have currently an alternative data format storing the Planet. I personally consider it the best method to store data for rendering and routing and only requires a single table table to store all geoconcepts.<br>
<br>
The basic functionality is build on the concept we had here, in OSM, before called segments. Each segment is materialized by the database, thus will return a segment that can be directly plotted. For all *non* areas this is sufficient. If you want on the other hand render an area you will be forced to create a list of the results that come back. [In GIS terms a circular linestring]. Using the data also used for routing the exact sequence can be restored by the renderer.<br>

<br>
Since an area will always be closed any segment can be taken to be build upon [as start point]. Even without the routing data the object can be fully connected, based on the start and endpoints.<br>
<br>
<br>
For the visual people:<br>
<br>
n1-------------------n2<br>
<br>
n1 is stored as lat,long<br>
n2 is stored as lat,long<br>
<br>
<br>
For a renderer this is more than enough. The extra database features come with constraints to make the following possible:<br>
<br>
<br>
n1--------v---------n2<br>
          |<br>
          |<br>
          |<br>
          |<br>
          |<br>
         n3<br>
<br>
Where v is actually a constraint that line n3 is constrainted to the center (50%) of line n1..n2.<br>
<br>
<br>
...what is available is done in plain SQL. [Commercial break]Ofcourse MonetDB was used for storing the data[/Commercial break].<br>
<br>
<br>
I was looking at implementing native rendering using javascriptsockets (aka just fetch tuples directly from the database), because I want live editing :)<br><font color="#888888">
<br>
<br>
<br>
Stefan<br>
</font></blockquote></div><br></div>