On Jan 14, 2008 10:22 AM, Karl Newman <[EMAIL PROTECTED]> wrote:
> On Jan 14, 2008 10:11 AM, Lambertus <[EMAIL PROTECTED]> wrote:
>
> > Hi Brett,
> >
> > Lets see if I can put this down nice and short: I've had a little chat
> > on the IRC today about splitting the planet file into subtiles for my
> > Garmin endeavors. I complained about missing ways where they cross tile
> > boundaries because of how the bboxes are extracted from the planet file
> > and that this is quite a showstopper for the Garmin maps.
> >
> > Now, this could be solved using the completeWays option but that is not
> > useable when processing the whole planet file. Also the ways do not stop
> >
> > at the edges of the tiles. So RichardF (et al) came up with an idea
> > where large tiles were extracted which would be post-processed to
> > produce subtiles with ways neatly cut on the edges. This would lower the
> > amount of RAM needed to maintain a list of nodes and ways that are
> > involved significantly, resulting in a workable solution. We discussed
> > some more about this and came to the conclusion (Bobkare/Kleptog) that
> > it might be a nice addition to Osmosis to add this as a new feature. How
> >
> > about that, eh?
> >
> > Attached is the (long but condensed) IRC log which shows the idea (and
> > some spin-offs) as described above in some more detail (although in bits
> > and pieces).
> >
> > What d'you reckon? Is this something for Osmosis?
> >
> > Regards, Lambertus
> >
> >
> Lambertus,
>
> I know you directed that at Brett, but the tiling task is something I was
> planning on writing for Osmosis (maybe as a plugin). I'll take a look at
> your attached conversation. Brett is working on a Dataset implementation
> which could make this task a lot easier. It allows random access of
> entities, and could conceivably allow you to create all your tiles in one
> pass instead of having to break it down hierarchically as you mentioned.
>
> One problem is that I'm pretty time-constrained right now. I'm looking for
> a new job and trying to train my replacement. If I don't get to contribute
> code, I'd like to give some input at least. (I'm planning on using it for
> making routable Garmin maps.)
>
> Thanks,
>
> Karl
>
Okay, replying to my own email. I just scanned through your chat log (it was
shorter than I originally thought). Let me post my ideas here, with an eye
toward generating tiles which can be used for routable Garmin maps.
1. "Synthetic" nodes will be needed on certain ways and polygons. I would
recommend adding a node at the boundary and give it a special tag such as
"tile:synthetic=yes". If there's already a node at the boundary (or close
enough, within some radius such as the 1m Garmin map resolution), then just
use that node, maybe with another tag ("tile:edge=yes"?). Note that
hard-clipping at the boundary has some special considerations. For example,
consider a way which wanders back and forth across the boundary. You'll have
to split it up into multiple ways, and it would probably be a good idea to
keep track of the original way id. For closed ways (polygons), you'll have
to join the synthetic nodes together, slicing out the nodes which are
outside the bounding box. It gets weirder with multipolygons where the inner
polygon is split by the boundary--you'll have to join the synthetic edge
nodes of different ways together (the outer polygon and the inner "hole").
2. For routable ways, don't use synthetic nodes. On Garmin devices, routing
nodes are basically intersections/turn points or way endpoints. There is a
restriction on Garmin maps for how close routing nodes can be (I think 3
meters), and adding synthetic nodes risks putting them too close together.
(Too-close routing nodes may be a problem we have to deal with anyway.) Some
sort of rule could be devised, such as discarding all nodes outside the
boundary on the right and bottom edges, and retaining one node outside the
boundary on the left and top edges (so it will extend into the next tile and
match up with the way when stitched together later on the GPS). The nodes
which are the new end nodes would have to be tagged as such (Garmin requires
them to be indicated as "external" routing nodes for later stitching).
3. I'm thinking of making this a two-part operation. The first part would
just treat all ways generically and go through and insert the synthetic or
edge nodes but leave the ways otherwise intact (complete). The next part
would decide what to do with the ways based on a configurable rules file. If
they're routable, then remove the synthetic nodes and treat them as in #2
above. If the tags indicate that they're polygons (closed ways), then
connect the nodes as described in #1. Then the synthetic node part could be
left alone even if new tags were to be supported.
I'm intending to write my routable map creator to render into Polish Map
format for input into cGPSMapper, but there's no reason that it couldn't be
switched to directly write the binary img file format once it's
reverse-engineered.
As I've mentioned before, I wrote an XSLT program to create routable Polish
Map format from OSM data, but it only works on tiny data sets. However,
based on that experience, I have a good understand of the routing
requirements for cGPSMapper now.
Okay, there's my brain dump. Hopefully it makes some sense. I've been
thinking this through for a few weeks. Just haven't had time to code
anything yet. I'm still trying to finish up a big Osmosis patch to support
the "bound" element (plus a ton of unit tests).
Karl
_______________________________________________
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
