[OSM-dev] Data source for robot

andrzej zaborowski balrogg at gmail.com
Tue Oct 12 19:49:55 BST 2010

On 12 October 2010 19:27, Apollinaris Schoell <aschoell at gmail.com> wrote:
> On Tue, Oct 12, 2010 at 7:41 AM, Peter Budny <peterb at gatech.edu> wrote:
>> Andy Allan <gravitystorm at gmail.com> writes:
>> > Also, I'd advise you to leave TIGER data to one side. A very high
>> > percentage of major roads in OSM in the US have been edited, many
>> > multiple times
>> What about the minor roads?  State Roads are exactly the ones that
>> aren't major, and there are a lot of them.  Most states have at least
>> several hundred, and a few like Kentucky and Texas have more than 6000.
>> That's a /minimum/ estimate of 20,000 roads, most of which haven't been
>> touched because they're in rural areas.
> if they haven't been touched what is the advantage to touch them by a bot or
> other automatic edits? obviously they are either good enough in there
> current status or no one cares about it. there is 0 benefit in automatic
> edits.

The advantage is that someone who starts caring about the area can
spend their time on surveying and more useful things, instead of doing
things that could have been done automatically.  Another advantage is
that you get a unified schema, not three different schemas (refs on
ways / tiger:base_name_3 on ways / refs on relations) and you can do
things like calculate the length of all state highways more simply.

> taking original tiger 2010 data  will be the much better choice for
> any application

If you have a tool (like a renderer) written to deal with database A
and its data model then the extra complete and precise data in
database B is 100% useless to you.  Specially if B covers a single

I don't take the point about having a highway shield renderer working
before starting to build up the data.  The data is not there only for
the renderers, and hardly anything in the database is done as hints
for the renderer.  The renderer is just another tool that has to adapt
to whatever schema is there, and frankly the route relations schema is
a million times more maintainable that ref / name / etc tags on each
chunk.  Of course all of the schemas could work, OSM has until
recently worked fine without relations, but they were added for a good


More information about the dev mailing list