hi danny --
> > OSM doesn't have an exact link between street and city. I'll see what I
> > can do about that.
> > Could you help me out by describing in a few words what the ranges are ?
> > The tables above, and what should the functions
> > buildmap_range_add
> > buildmap_range_add_no_address
> > buildmap_range_add_place
> > be called for ? (Which type of thing do I find in an OSM file and then I
> > should call one of these functions.)
> I looked around better and found this in the README :
> * THE RANGE SECTION
> The range section describe the street addresses. This is the section
> the "find by address" feature of roadmap is based on. It also
> contains the name of those lines for which there is no address
> The range section is made of the following tables:
> [range.bystreet] for each street, the ranges that belong to the
> [range.bycity] the list of ranges by street, broken for each city.
> [range.addr] for each range, the street address numbers.
> [range.noaddr] reference to the street for the lines with no
> [range.byzip] for each range, the ZIP code.
> [range.place] for each place, the city it belongs to.
> [range.bysquare] for each square, a street search accelerator.
you should look at how these tables are used in the tiger
buildmap code. essentially, street sections are notated with the
addresses that appear on both the left and right sides of the
street. i added the noaddr table recently when it turned out
that it was impossible to search for streets for which there were
no addresses listed. (some rural roads are like this.)
i've never really understood the concept of "places" in that part
of roadmap. i believe they're an artifact of how tiger stores
its data, and it might be worth looking at the tiger schema to
see what they really are. i do know that they're different (i
think) from the buildmap_place.c stuff that steve woodbridge wrote:
buildmap_place was implemented, but there is no corresponding
roadmap code to read what it creates. don't know if these are
the same "places" referred to in range.place or not.
> Let's see if I understand this.
> Buildmap could be made to create "place"s from nodes in the OSM file
> under some conditions. This node :
but roadmap has no way to display them, currently.
> Second is that the function roadmap_street_block_by_county_subdivision
> only looks in range.bystreet . This looks wrong, it should look in
> range.noaddr too. Or is that the wrong type of access to these tables ?
you may be right -- as i said, i added the noaddr table, and
might have missed this. (but i also don't really know what that
routine does, so you would know better than i.)
> Third, either buildmap_osm or roadmap should be told to do something
> sensible about the city/street relation. In the absense of decent data,
> an approximation (e.g. a street belongs to a town if it's less than 5 km
> away from the town center, that number can of course be overriden by the
doesn't OSM have a clear way of describing this? without good data, we can't
really do much.
> My guess would be that this kind of functionality belongs in
> buildmap_osm, but this remark in roadmap_street.c makes me wonder :
> /* FIXME: at this time the place -> city mapping is totally unreliable,
> * because the two do not always match. For example, the Pasadena city
> * and the Los Angeles place intersect, which cause all of Pasadena to
> * be included in Los Angeles. Bummer..
> Comments ?
like i said -- i've never really understood this aspect of roadmap.
steve woodbridge might have some advice -- cc'ing him, in case he's
filtering the list into /dev/null. :-)
paul fox, pgf@... (arlington, ma, where it's 67.3 degrees)