[OSM-dev] Data source for robot

[Andy Allan]

On Tue, Oct 12, 2010 at 2:46 PM, Peter Budny <peterb at gatech.edu> wrote:

> Relations are the cleaner solution here.  You /could/ accomplish the
> same thing with regular tags, but who wants to see symbol=*, symbol_1=*,
> symbol_2=*, etc. on every way in a city?  (Or worse, a giant symbol=*
> tag with semicolon-separated URLs?)

Great. So the way to fix this is to first make the data consumed. I'd
suggest working on osm2pgsql so that it supports route relations
cleanly, as you've described. Then, you can sit back and let the
community take advantage of the new rendering system, and implement
route relations themselves in whichever fashion motivates them the
most.

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, and in my extensive experience many times turned from
single to dual carriageway. There's very little to be gained from
considering TIGER data in the context of OSM, much better to consider
current OSM data itself.

Finally, if you think there aren't enough people to do the editing
work suggested, then the solution is to add more people, not more
scripts.

If you want an analogy, then consider cycle routes. Back before
relations even existed (hah!) everything was tagged as ncn_ref on the
way. This had the problem that you sometimes needed semicolons to
store the route numbers, and this looked ugly on opencyclemap. So we
implemented cycle-route-relation parsing, and left it to the mappers
to create the relations where they were needed. Nobody ran a bot, and
it sorted itself out. That's the best way to solve this problem, too.

Thanks,
Andy