[OSM-dev] Very long ways have been split (was: Status of Database Server after 0.4 Upgrade: Fragile)

[Jon Burgess]

On Mon, 2007-05-14 at 14:32 +0100, 80n wrote:
> On 5/13/07, Jon Burgess <jburgess777 at googlemail.com> wrote:
>         How about
>         
>         Plan B:
>         =======
>         - If a way is too large to return, don't return it!
>         - Instead perhaps we can add a new tag which says something
>         like:
>         
>         <way id=12345 segs_excluded="true" seg_count="5000" > 
>         <tag k=... >
>         [ more tags, but no segments ]
>         </way>
>         
> 
> Wouldn't this mean that when the 5001th segment is added the whole way
> becomes completely and permanently uneditable? 

> Any editor that uses the API would never be able to download such a
> way and so could never modify it.

I only saw this as small part of the solution. This was only intended
just to enable current renderers and tools to download data using the
map API without hitting a 500 error due to the amount of data needing to
be returned. Yes the data would be incomplete, but better than no data
at all (well, depending on your point of view).


> Admittedly a second call could be made to explicitly download the
> incomplete way but that gets us back to the JOSMs Download Incomplete
> Ways method which I never thought was very satisfactory. 

To be able to edit the data tools would either need to use a different
API call (e.g. /way) to get the full data or perhaps use plan(c) to
allow a partial list of segments to be transferred via the API. 

I don't see this as being anywhere near as bad as the incomplete way
problem. I think the main difficulty with this was that the editor had
to manually detect the condition and the only way it could successfully
upload or edit the data was to download the rest of it (which had no
specific API support). If we can provide a reliable way to detect this
condition and also API features which enable the editors to work with
subsets of ways then the code to handle this should be much simpler than
the existing incomplete way handling.

	Jon