> You also have to realise just how many tags there are. > On nodes and ways there are close to 1 billion tags, comprising of > about 50 million distinct key-value pairs (this was the last time I > counted which was a while back). > > So while you'd save on space, the table join to get the tags back > wouldn't be that cheap.
I guess there are a lot of key-value pairs, but joining tables is what relational databased are made for. > As far as typos go, well, the typos are in there too so they'd turn up > in your autocomplete if you used it verbatim. You also have to > separate out tags used on nodes, tags used on ways, and tags used on > relations. The api change would be a good time to clean out most of the typos. with the node_tags, way_tags and relation_tags table (sorry i've completly forgotten these above), they are allready separated. > As far as your map features extension goes, this wouldn't need to be > real-time so it could be done on a different machine by processing the > planet dump. I think there would be a lot of value in a site which > could achieve something along the lines of an extended TagWatch, but > you probably don't need an API change to do it. I agree with you, that the map features dosn't need to be created realtime. An extended TagWatch could probably be a better solution than a map feature extension. But I guess, TagWatch would also profit from this change. The changes would more be an enhancement of the API (getNodeTags/ getWayTags/getNodeKeys...) than a change. Raphael _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
