[OSM-dev] Fwd: Relations without members?

Karl Newman siliconfiend at gmail.com
Sat Oct 13 00:15:23 BST 2007

Forgot to "reply-all" to get this back to the list.
On 10/12/07, Brett Henderson <brett at bretth.com> wrote:
> As for your new requirements, could you define what you would like done
> with each entity type at the area edges (I say area because this applies
> to more general polygon extraction also).  We can then figure out a way
> of building a tool to support them.
Well, for polygons (closed ways), I was thinking about creating
synthetic nodes right at the border as Frederik suggested and joining
the polygon straight down/over to the continuation of the way where it
comes back inside the bounding box. Then when the sections are
recombined, they'll butt together. It may be possible to treat this
the same manner as I was thinking for ways (keep one stray node), but
it could be a real headache when dealing with nested polygons if the
nested polygons ALSO are split by the border. Maybe the synthetic
nodes at the border is the best way to treat this all around.
> Perhaps one way of supporting problem ways is to keep all nodes where
> one or two nodes stray outside the box, but drop all other nodes in
> between the first and last stray node.  This would make the ways run off
> and back onto the map in the correct line.  Not sure how that affects
> any routing algorithms.
That would probably be fine, but would have to be split into two
separate ways (between the two stray nodes) by the routing algorithm.
For Garmin GPS maps, the stray nodes need to be marked as "external"
to link the routing with the external nodes in the continued way in
the adjacent section.
> As for supporting streaming, that is more difficult.  Classes such as
> SimpleObjectStore will help and are what I used for file-based merge
> sorting of planet sized files where I need to revisit objects many times
> during a sort.  Although SimpleObjectStore is very simple and is not
> indexed in any way, other classes such as ChunkedObjectStore go some way
> towards solving the problem.  A fully indexed object store with random
> lookups will require some more work though, it may even be worth
> thinking about a proper database like berkeley db for this although that
> is not necessary if you're prepared to get your hands dirty and roll
> your own.  Another problem you'll face when doing this is speed, my
> current object stores use java object serialisation which is very slow,
> I'd like to implement a custom serialiser and deserialiser for osm data
> types which should provide huge performance speedups.
Yes, it may be necessary to work with a database--the nature of this
project is really a random-access relational problem which may be
well-suited to a database. The concept of assigning types to ways and
setting up the routing between ways via shared nodes is not difficult,
but the problem is how to do it with massive data sets without pulling
everything into memory. It's easy to deal with the edge problem once
by manually dealing with the ways that cross the borders, but I
anticipate generating new GPS maps on a regular basis as the map data
is updated, so it needs to be something that can be automated.

More information about the dev mailing list