On Mon, Dec 29, 2008 at 10:26 PM, Stefan de Konink <[email protected]> wrote: > Some people wanted to limit ways/relations to 2k of nodes. If you do > allow relations to have all these extra subrelations then what are you > going to solve in the end? This is enforcing a clueless limit and not > solving the fundamental problem why this limit is justified; and no that > has nothing to do with data storage.
practicality. since we all agree that no-one wants to download a 100k+ node way, there are two immediately obvious solutions: change the API to return partial ways or disallow ways longer than some arbitrary limit. the former requires many changes on the server and client, the latter requires many fewer. the former might be a better solution (fsov "better") and we would welcome patches to the server, josm, potlatch and merkaartor which implement it. > As I mentioned earlier, there is no need for even the concept 'way'; > since you can store a relation with tag highway=whatever. So fundamental > issues: > - the tables are too verbose (not normalised) practicality. this is a legacy problem - relations were introduced as unordered sets to solve a particular problem, but their use has since outgrown their original conception. in 0.6 the relations are able to totally model ways, but in 0.5 they are not. there are several other non-normalities in the tables (i.e: *_tags), but ways/relations is not one of them. this may change (or be "fixed", depending on your point of view) in future API versions. as shaun said: "one step at a time". > - the tables imply limits that are not required from a database standpoint the API certainly does, but this is related to the point above. just because there is no technical reason from a database standpoint doesn't mean there isn't a reason. > - the practical usage of limitations (only fetch what you can observe) > is not exploited at all, while this is an issue for a renderer and a > typical client that wants to use the data it is exploited in the map call to return only visible nodes, ways and relations. > Anyway the resolve scenario sounds like Microsoft, "you cannot use > character blablabla in your filename, because we say so". NTFS disallows "/", as do most unix filesystems. macos x disallows ":" http://en.wikipedia.org/wiki/Filename#Comparison_of_file_name_limitations these limitations are usually imposed to prevent confusion. i.e: "/" is always the root directory, not a file called "/" in the current directory. cheers, matt _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
