[OSM-talk] Finding a particular street on the GPS

[Karl Newman]

On Dec 23, 2007 11:42 AM, Christoph Eckert <ce at christeck.de> wrote:
> Hi,
>
> > Actually, for the full-featured version that does everything with no
> > restrictions, it's USD2800... However, you can get free access to that
> > version online if you're willing to share your maps with the world.
> > It's at mapcenter.cgpsmapper.com
>
> this service has somewhat limited routing capabilities IIRC.

I don't think so--I think it's the full, unrestricted version with
routing and everything.

>
> > The other complicating factor is that
> > there is currently no path from OSM data to cGPSMapper format. That's
> > a project I'm planning, but I need to get some key pieces in place
> > first. I actually rewrote the osmgarminmap XSLT stylesheet to
> > transform OSM data into routable cGPSMapper format, but xsltproc
> > chokes on even moderate-sized data (10 MB), so it's not usable.
>
> xsltproc will eat a lot of memory and thus is of less use for huge amounts of
> data (like osm provides).

Yes, I realized this quickly--it's the wrong tool for the job. I did
it as a quick proof-of-concept (which worked), and to further my
understanding of the cGPSMapper input format.

>
> > The other big factor is that there is no agreement on how to do
> > street/house numbers yet, so there's limited data in OSM anyway. I've
> > discussing the proposal on the Wiki recently and it's been a bit
> > frustrating because nobody seems to get my point.
>
> Wasn't it possible to do it by a relation?

Yes, absolutely, but everyone keeps trying to make a single relation
into a number range, instead of the simpler and more flexible case of
numbering single points with one relation at each point where you want
to provide a number, with the number range between the points implied
based on the numbering scheme indicated (read my proposal for more
details--it's really quite simple). This is the format similar to what
cGPSMapper requires, and it makes a lot of sense. The GPS
manufacturers solved this problem already; let's not re-invent the
wheel.

Karl