[OSM-dev] ROMA servers down - osmosis large way problem

[Matt Amos]

On Mon, Dec 29, 2008 at 10:26 PM, Stefan de Konink <stefan at konink.de> 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