[OSM-dev] Cartagen - client-side vector based map renderer, dynamic maps

Jeffrey Warren warren at mit.edu
Thu May 7 17:10:41 BST 2009


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.
Just curious, how does Mapnik or Omsarender do it? Surely they don't
actually render every node of a way for very large bboxes?

Jeff


On Wed, May 6, 2009 at 8:51 PM, Stefan de Konink <stefan at konink.de> wrote:

> Jeffrey Warren wrote:
>  > c) trying to serve partial polygons... I'd like to try plotting only
>
>> 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.
>>
>
> 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.
>
> 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.
>
> 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.
>
>
> For the visual people:
>
> n1-------------------n2
>
> n1 is stored as lat,long
> n2 is stored as lat,long
>
>
> For a renderer this is more than enough. The extra database features come
> with constraints to make the following possible:
>
>
> n1--------v---------n2
>          |
>          |
>          |
>          |
>          |
>         n3
>
> Where v is actually a constraint that line n3 is constrainted to the center
> (50%) of line n1..n2.
>
>
> ...what is available is done in plain SQL. [Commercial break]Ofcourse
> MonetDB was used for storing the data[/Commercial break].
>
>
> I was looking at implementing native rendering using javascriptsockets (aka
> just fetch tuples directly from the database), because I want live editing
> :)
>
>
>
> Stefan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20090507/79f62754/attachment.html>


More information about the dev mailing list