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

Stefan de Konink stefan at konink.de
Tue Dec 30 10:38:18 GMT 2008

Matt Amos wrote:
> 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 latter still requires the same client/server modifications + 
modifications in all current node relations. Hence it will cost more time.

>> 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.

Even in 0.5 relations can be ordered using the type='...'.

>> - 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.

I think you mean intersect here or not? Because if you already have a 
call that gives back a truely right map. The only thing that should be 
implemented in the editor, that you cannot edit nodes on the boundaries. 
Now that actually is trivial (begin and endpoints of the polyline).

>> 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.

There are more things that are less obvious ;)


More information about the dev mailing list